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ABSTRACT 


A new notation is introduced for representing real-time 
scheduling at the task and event level. These schedules are called 
control structures. The primary constructs included which direct the 
flow of control are sequencing, iteration, and preemption. Additional 
notation allows the representation of interrupt masking, task 
termination by external events, task restart as well as resumption 
from the point of preemption and codestripping. Algorithms are given 
for finding the preemption structure of a given conmtrel.structure in 
the notation. 


The types of representable control structures are classified by 
the topology of their Control Flow Graphs. It is shown that although 
branching is allowed in the preemption structure, a tree-shaped 
preemption structure cannot be represented. Both partial and total 
orderings of tasks and interrupt priorities are supported, however. 


A. terminology for describing. real-time properties of control 
structures 1s developed, and_it. is seen that. without ‘certain assumptions 
drawn regarding real-time serformance of # ‘control. ‘structure. "A series 
of algorithms is presented which make use of these assumptions, and 
find values for task execution times in the presence of preemption. 
The algorithms can analyze control structures containing the principal 
contro] features; suggestions are given for further development of 
algorithms which can a. any representable control structure. 
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1: introduction 
In an article entitied "Toward a discipline of reattime programming" [Wirth 
77b], Nikiaus Wirth has divided programming into three categories based on the. in- 


creasing complexity of validating their programs: 


1. Sequential programming 
2. Muitiprogramming 
3. Reattime. programming - 


In a reattime system, a program may be attempting to control or to react to 
certain external processes which cannot bé forced to cooperate with ‘programmed 
processes through use of a synchronization prinitive such as a semaphore [Dijkstra 
68] or a monitor [Hoare 74]. in order to ‘coordinate itself with these external, 
nor-programmable processes, the real-time program ‘mist Know something about its 
own execution speed. Thus Its correctness will be dependent on the speed of the 
processor on which It Is run; but this Is not’ a ‘property ofthe program Itself; Wirth 
Identifies‘this as the éssential distinguishing feature ‘of réat-time programming. 

This thesis does not directly address the lssilé of Validating real-time programs. 
Instead; it ‘deats with the répresentation of schédules for real-time programs called 
contro! structures, arid’ some aspects of feasuithg ‘teattime properties of the 
resulting control structures. In the sense that knéwledge of these real-time proper- 
ties may be a prerequistte Tor validation’ of a reat titie program, the work presented 
here dees tepresent'& contribution to one aspect of the Validation problem. 
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1.1: Related Research — | : 

Most of the previous studies in the field of rea-time programming have been 
centered on one of two major areas, the design of languages for real-time program- 
ming, and scheduling to meet reattime deadlines. | . . 

The development of languages for reattime programming can be split between 
two approaches; the extension of existing languages ‘[Bénson 67; Freiburghouse 
77; Ormickl 77; Philips 76; Wirth 77a], and the creation of entirely new ianguages 
tailored to the requirements of real-time programe fHennessy 75; Kieburtz 76; 
Schoeffier 70]. The essence of these efforts has. been to provide some interface 
between the reaFtime program and the scheduling of itself and other programs, et 
ther through access to the processor's interrupt system, clocks and/or timers, or 
by influencing the processor's scheduling routines. Such features provide .onty -a 
tow level capability for determining a process’ real-time behavior; in some cases it 
may be possible to think of all the timing interactions. that, could Impact on the 
correctness of a reattime system, but the burden of doing so has usually fallen 
most heavity (and often. totally) on the programmer. Decisions as basic as.assign 
Ing priorities to different tasks must typically. be made by. manual analysis, in the 
hope that nothing has been overlooked. As the size of. the system Increases, the 
complexity of the problem grows as well, until manual, analysis becomes extremely 
tedious and error-prone, if nat impossible. ; 

Ideally, a programmer could submit his reaktime. response, requirements. along 
with his programs, and elther have them scheduled. appropriately, or be.told that. his 
requirements cannot be met by that particular system. Some systems (such as the 


CONSORT system of the Domain Specific Systems Research group at MIT) have 
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been developed which can do this for a limited class. of ‘programs, but to the 
author's knowledge no one has yet ‘andean a systenr to do‘this in gendrat. Howe 
er, considerable research has been done on scheduling tasks in the presence of 
hard reattime deadlines. 

Most of the significant results obtained have been: based on’ restricting attdén 
tion to Ilmited classes. of. control: structure ‘types: For exampie; ina multiprocessor 
environment where there is a partial: ordering: of tasks but no Iteration dutside of 
tasks, [Manacher. 67] gives an algorithm: which. wii: construct near-optimal task lists 
(execution orderings) for almost any combination of task run times: and: deadinés. 
If the schedule Is full to capacity with -¢asks - whose: completion times are 
guaranteed, his strategy allows. the system?to take of. additional ynguérenteed 
tasks. without affecting the guaranteed: statue of: thesd tasks already scheduled. 
His scheme does sot consider ithe effects of preemptich, however. “Seriin [Sertin 
72] and Liu and Layland [Liu :73] have. .independentty. studied. the problem of 
scheduling tasks. which are iterated but have no=relative orderings. Serfin gives 
scheduling algorithms based on fixed priorities, ‘time: siiciag, and relative -urgency.. 
The last is a dynamic priority scheme, where the processor re-evaluates the prior- 
ties of each task at every Interrupt, and selects for execution the one with the 
earliest deadiine. This method is shown to produce a sonenuie which meets jeak: 
time deadlines if any schedule will, but Soriin's analysis neglects | the overhead of 
context switching. | . 

A different approach is taken by [Hennessy 75; Kleburtz 75) in their anOrOe te: 
cessor language TOMAL; instead of using an es oyraten. they have a com- 


plier insert calls to a task control monitor (which is “orsated along with the acl: 
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tlon of a set of programs) at specific points in the compiled code. This provides 
assurance. that the task control monitor wilt: get contret within a finite and boirided 
interval, after.each cadestrip, as the code between monitor calls is-named. This is 
simlar to a time slicing system which allocates execution time im fixed amounts to 
each task, but the time slices are synchronized with. program execution. The 
length of the codestrip is daterminad ‘by: tha response time requirements of the 
task, and the compiler can determine: whether: the programiner supplied require- 
ments are in- confict. The notation given in: this thesie has: the capability of 
representing codestrips. 

A werk which is relatad:to the: praesent one and in fact complementary is that 
of Teixeira. [Teixeira 78]. Much of the - terminology used: here was ‘developed 
there, particularly that of Chapter 6, wheres. algorithms for seasuring real-time pro- 
perties are developed. Teixeira. also used theiregular “expression notation of 
Chapter 2 to denote sequencing and iteration of tasks. His atudy centers, howev- 
er, on finding schedules :to meet reaktime constraints; the orientation of the 


present work is described in. the following section.: 


1.2: Objectives 

The principal goal of is reseae is twofold; Hua develop a convenient 
representation for reattime control sinichures: and to "demonstrate how —_ . 
representation is useful as a basis for serene rear tne: properties bed seciec 
control structures. 


seat 


The representation as developed models control structures at the task and in- 
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terrupt level; the tasks are assumed.to be self-contained program units whose ex- 
ecution time is bounded, and interrupts are: represented as occufrences of event 
variables. The event variables could.ba used.to represent any ‘event however, 
which might be synchronous or asynchronous with respect to the executing task. 
The notation can represent total and partial orderings among its tasks, and iteration 
of tasks at a single priority level..or across. several. priority ‘levels. As well as 
representing conventional. single and. multtHevel interrupt structures, the control 
structures given here cap represent several unconventional preemption: structures, 
including branched. structures. where each. branch--has -en individual preemption 
structure which may itself be branched. 

As well as fenienautings* this basic framewaik: Uthe capably | is provided to 


Soba Sh ogee 


represent: . 


1. Codestripping as previously described. 


2. External termination of a task or “group ae tasks by an event 
occurrence (as opposed to ecaictehenbe Preempting t them). 


3. Indication that a task ‘or group of tasks is = preemptible by _. 
@ set of events. 


4. The choice between réatiarting? & piéempted task or group of 
tasks from the beginning vs. resuming execution from the point of | 
7 interruption.” ery 3g in. a Book ge venga fey "a 7 2B % é, 


Thus a rather ‘general notation is siven, which in addition represents all of this in- 
eerie see ; 

formation rather Gompagthy: ‘The’ notation | may be aed in any application where it 

Is necessary to communicate something bout s a control structure of this sort, be it 


human to human, human to machine, or machine to pachine. in ‘the ‘second case, 


the specific applications In mind are representation of a control structure for 
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analysis, and for describing to a reaktime system what -sort of contro! structure It 
should establish for a set of tasks with reaFtime constraints. in this vein, the no- 
tation is quite independent of machine architecture; and ‘thus a subset of the 
language can be chosen for a target machine which supports the contro! features 
included therein. ' 

This leads into the second goa! of the investigation, which Is to demonstrate 
how algorithms can be developed which ascertain reaktime propérties for control 
structures of the language. There are several thie intervals which are probably of 


common interest to a large segment of users of realtime prograins, such as: 


1. The maximum delay between the occurrence of an event and 
the Initiation of its program. erate. Be 


2. The maximum time required to execute a set of tasks at a 
given priority, with preemption. 


3. The maximum time that may efapse without there being an ex- 
ecution of a given set of tasks. 


This is not intended to be an exhaustive ‘survey of real-time Properties, but rather 
an Introduction to the usage of the ‘notation as “the foundation, for such. analysis. 
Indeed, It is likely that each. reattime. system, hag. its. en eee requirements and 
characteristics; it is hoped that an appropriate subset “of the languege:. ‘can be 
meen to model eee cnerecteradee. ane pes cohen bechiseuares wien are suited . 
to. an applications s special needs. tn addition, “many epphcetios wi have natural. <a 
restrictions which lead Si simpler flgorthms; is is with Abert of illustrating this - 


oe ala ait 


point that several special case algorithms a are developed. 


Eihe 
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3: Outline of the Thesis 

The next chapter presents a context. free: grammar. fer.:the: control structure. 
ianigdaae: as well as giving the semantics for each construct. Sequencing, iteration 
and preemption are the principal features, with extensions added as ‘Seacribed in 
Section 1.2. Methods of cone the overall peresnece structure ofie a _ control 
structure are also presented. : = . - - 

Having introduced the notation, Chapter 3 presents the concept of a Control 
Flow Graph (CFG) [Alien 76; Fosdick 76), which gives a a A graphic representation for 
the paths of control flow dictated by a ‘given contel’s structure. A definition of ab 
solute priority levels is ‘derived from ‘a controf structure's CFG representation. Then 


able by the notation Is given, 


a classification of ‘control structure types represe: 
based on the > topology: of Gist ‘Cres. in adition, some. ‘types: of éontrol structures 
which are not rapiobatitable are dencitied.’ satteanane BES 

A terminology for.reattine properties. of . control structures is developed in 
Chapter 4; the requirements for knowing certain thinge: ebeut event timings In ad: 
vance is also discussed here. 

This leads into Chapter 5, where a hierarchical series of ap ciabalaoe Is present 
ed which are designed to find the worst cases for some of the reattime properties 
of increasingly complicated classes of control “structures. The most : general algo- 
rithm given is applicable to ‘the set of control structures which includes: the basic 
framework of " sequencing, ‘iteration cad. ‘prosmptind. ” The types of “modifications 
which would be required ‘to analyze any representable control structure are dis- 


wedge 2 Seer Ua eee 
cussed, although detailed algorithms are » not given. 
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2: A Notation for Real-time Control Structures 


2.1: itroducaon 

in this chapter a notation for representing reattime conta structures wilt be 
developed. The intention is to ‘provics a ome analytical tool which wil be suit- 
able for representing most of the possible ways. to share a Processor among the. 


maubars of a set of tasks. This wil include: 


1. Sequencing: a total ordering of tasks.to be executed.. 
2. Iteration: cyclic execution of some ordered set of tasks. 
3. Preemption: a partial ordering of taske where the occurrence 


of an event forces termination of execution of me . run- 
ning task and starts execution of a new. task... Lees 


A context-free grammar ‘will-be developed to defirie the syfitax of the representa- 


tion. it is.summarized in Appendix A.. - 


2.2: The pene Control Structure 
The reattine system to be perieceniee: is mocetet as . Side of procemi es fo 
be run, called tasks, a a control structure waren specifics the order (or possible ord 


ers) in which the tasks may’ be run, ais a pee which exscuee the tasks ¢ ac 


er Bs LBiM ee bre 


cording to the scheduling constraints specified by he control Suucure., 


Thus the flow of data batwoun tasks, if there s any, need not be a concern; ; 


Ht Is assumed that any execution ofdering needed to preserve the intended semar- 


-14- 


The Basic Control Structure * Section 2.2 


tics of the computation (data flow) will be embodied inthe contol structure. For 
example, if an output of task A is an Input of task @, thea, the control structure as- 
sociated with their execution should ensure that task A completes execution be 
fore task B begins. | eo | | 

Further, the detailed sow of jriformation ‘and Sontiel nthe task, le. among 
its Internal variables and instructions respeatively, need not. be of ‘concern elther. 
It Is. only, necessary that an upper: bound on the’ exectitict tiie of a task be esta- 
blished; this ls discussed further In Section: 4.2. 

A task will be represented by a task identifier ("<task id>"), which In most of 
the examples will be a single capital letter (though it need not be). Figure 2.1 


shows the grammar which defines task identifiers. 


<task Id> ::= <ietter>*] <task id> <alphanumeric> 
corer 18 Ce | 
<ailphanumétic> ::= Cietter> | <digit> 
” Fig. 2.1, ‘Syntax for task identifiers. : 
Next to a single t task, the » simplest thing to 0 represent la _ sequencing of two | 
or more teks ‘which ¢ are totaly’ ordered. This is done in the natural way, by listing . 
the task identifiers in the order of execution ‘of their ‘coneapondlag tasks, separat- 
ed by blank spaces for parsing. A string of one or more tasks will be called a 
basic control Hr tues or parc: hater Note. that it. is peresen rs. to list: a beck id - 


task Is executed more than once with zero or more other task executions 


more than ‘once: in-« <bawic és, to represit ties ae 
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sandwiched in between.’ The syntax is: 
| <basic cs> ::= <task id> | <basic cs> B <task id> 


where “"§" represents the blank space termina! symbol. 


The simplest contro! structure is just a basic control structure: 
<control structure> ::= <basic cs> 


Thus the grammar given so far is sufficient to represent single task execution and 


sequenced task execution control structures. . 


2.3: Flow of Control 
it is useful to formalize the notion of conten tows with nee to control struc- 
ture execution. The processor follows the “instructions” supplied by a control 
structure, doing both “applications-oriented" work (when itis actually executing the 
statements of a task), and “systems-oriented" work (when it is determining. which 
task to execute next according to the constraints. embedded in the control struc- 
ture). In either case, the actual machine instructions, being, executed at any time 
will be associated with a particular os dara in ad control eure representation: 
HK will be said that at that time the focus of contro! (abbreviated te) = at that . 


Bard 


symbol. For oxample, In the following control structure: 


1. Every occurrence of a task id In a control structure represents a separate in- 
stantiation of that task, with its qwn private atate. This. ja.ased ta.model reer - 
trantly codéd routines. 
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AB 


when instructions of task A are executing, LC is at A; when instructions of task B 


are executing, LC is at B. 


2.4: Closed Control Structures 

It is desirable to introduce parenthesization for the grouping of task id’s in the 
natural way. In particular, this will be needed to Indicate the scope of the various 
special symbols which will be used for iteration, pfeéemption, etc. It will also be 
helpful in constraining the class of fegal control. structures to exclude nonsensical 
ones, such as those in which some tasks can never execute, ragardiess of. preemp- 
tion timing considerations. Parenthesized | (subr)control. structures will. be called 
closed contro! structures, and the class will be added to as necessary for addition- 
al representationa] power. At the top level, closed control structures will be includ- 
ed in the set of legal control structures. Figure 2.2 gives the syntax for closed 
control structures; a syntax is also given for éoead ree nractate lists, which 


will be needed fater to represent more compiex contro! structures. 


<control structure> ::= <basic cs> | <closed cs> 
<closed cs> ::= (<basic cs>) | (<closed cs> <basic cs>) | (<closed cs list>) 
<closed cs list> ::= <closed cs> | <closwd'os list) <closed cs> 


Fig. 2.2. Syntax for closed control etructures. 
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2.5: iteration 

Most realtime process control applications require the periodic repetition of a 
certain task or sequence of tasks. sorowing from the notation of reguiar expres- 
sions, the asterisk is used to indicate a endiess repetition of a control structure. 


ite BNF: 
<Iterative cs> ::2 <basic ca>* | <closed cs>* | <basic cs> <iterative jas 
The use of ** le most easily explained by examples: =. 
AB* = MBP SABBESSB... 
(ABP ZEABABAB... 
From a flow of contro! viewpoint, when LC réaches an asterisk following a right 
parenthesis, ft returns to thie matching left patenthes!s. If ft reaches an asterisk 
following a task Id, It repeats that task. 
The final expansion of the top-level definition of coritrof structure Is: 


<contro! structure ::= <basic cs> | <closed cs> | iterative cs> 
2.6: Preemption 


2.6.1: Preemptibie Control Structures | 

With the class of. control atructures.idefined- 20. far, the: enly execution se 
quences possible are those in which the order of task execution is entirely 
predetermined (static). in many situations, a processor wil need to respond to 
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asynchronous events. such as interrupts, which may nét occur at predictable times. 
It may be. desirable. to have- auch events«trigger the execitiin of a different part 
of the control structure than was previousty in contrel.° Informatly, this will be 
modelled by placing sub-control structures Into the overall contro! structure in order 
of nondecreasing priority. Demarcation of the priority levels is achieved by indi- 
cating that a control structure Is preomnls: Fours 2. 3 Bute the Syntax for 


lopeds 


preemptible control structures. Preemption Is initiated by occurrence of a Particu- 


eet > Err te 


lar event (which may be complex)! so an event variable Is included which stands 


for the event. 


<preemptible cs> : = <control structure> / <event var> . 

<event var> ::= e<integer> 

<integer> 328 <digit> | <integer> <digit> _ 

<closed cs> ::= (<basic cs>) | \cotoeed ce? Seer cs>) | (<closed cs list>) | 


(<preemptible cs>) | (ccieked éa3 bola cs>) 


Fig. 2.3, Syntax for Preemptible contro! structures.. 


‘Consider the following simple example, which models a control structure with a 


single level of interruption: 
((arye1)8)* 


The interpretation of this controt structure. Is: that A-runs repeatedly witil event e1 


1. The event variable itself is not complex, but it may represent a complex event. . 
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happens; this initiates 8, which executes once; then EC returns to A*, 

The aext section will describe: how mere complex control structures are 
represented (using the above syntex), such as those having tultiple levets of 
interruption. 


2.8.2: Multiple Priority Level Control Structures 

informaity, event variables fie at the interface between orl structures of 
different priority, the control structure to the left of the "/Cevent = construc: 
tion having the tower priority. Rta ia the lemee prlodiy tonne airuetice when 
the event happens, it wil move to the control structure immediately to the right of 
the event variable. _ 

Thus a control structure with three priority levels might appear as: 

(€@(A B)*/01)C D)02))* 

The preemption structure (for each event, the tasks which it may preempt) is fairly 
straightforward here; e1 preempts A or B, 82 preempts A, 8, C or D. But the nota- 
tion is capable of representing more cone control some and a sathod of 
precisely determining the ptieiaption structure s needed. : 

The "Interrupts" or "preempts" relation is transitiva; if e1 interrupts A, initiat- 
ing C, and C Is Interruptible by e2, then A Js’ Interruptible by @2. Moreover, all 
tasks of a single basic controj. structure: wil run at the dame priority tevel, so basic 


control structures can be considered as units, rather than examining the preemp- 


1. Although a fater section will introduce the capability of masking specific Inter- 
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tion of individual tasks." 

The “interrupts® fetation witt now ‘be forinatized, Te. Tt wet be established clear 
ly for each event in a control structure aiich: basic control structures it may 
preempt. The set of tasks which are Interruptible. by 3 a \ certain event will be re- 
ferred to as the scope of that event. The interrupts" relation for a control struc- 
ture will be represented ey a Boolean matrix 1 with nm rows and columns, where nis 
the number. of basic control ‘structires: ‘int ‘the: ‘Contr: Structure being analyzed. A 
single basic cs. is -asseolated with: each row is anit cofumn’ 4, for 1 ‘s. ign. The 
basic cs associated with row (and comme) # Pow be’ teterrei to’&s "basic cs /." 

The first event to the left-of each’ baste cs wit be’called that basic cs’s /ni- 
tiating event. \f I[/,j] = 1, it means that basic cs / runs at a higher priority. than, 


basic cs j; in nee it means mat basic cs he Anjtiating _ event can preempt 


baa 


Rae 


basic « cs i. The matrix ; Is mane ane according ia Bs Aaigorithm., given. in Figure .2.4. 

This matrix specifies which eventa cause praamptions across the border 
between adjacent priority levels. Since the “interrupts" relation is transitive, the 
transitive closure of this inftial:relation ts the complete “preemption stractiré; ' this” 
specifies, for each event sl hs) control etuctire, exactly which basic. cs's it can. 
preempt. Computing the transitive @ coaure of he relation represented by I is. 
straightforward. Let 1+ be the transitive: closure of I. Then + = i+ en oe 
where + is normal matrix. siddition. ‘Boolean ‘matrix ‘muttipiigation Is performed like 


regular matrix multiplication ‘except "AND is ‘shbstituted for ‘TIMES’ and ‘OR’ for 


rupts while a particular task is executing. 
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Algorithm 2.1: 


1. Let » be the number of basic-ce's In. the. control structure. As- 
soolate a unique Integer from 1 to n with each basic os. 


2. Initialize | to be an nxn matrix of zeroes. 
8. For each basic cs /, do steps 4 and 6. 


4. If basic cs / has no Initiating event, leave row / of I ‘peat to 
ail zeroes. ; 

6. If bealc ca / has an initiating event 9, find the control struc- 
ture Immediately preceding the construction "/e." Call this “con- 
trol structure k." By the syntax of preematible: osateal structures, 
control structure k will be either a basic, closed or iterative cs. 
For each basic ca / In control structure-k; set if) equakto 1.- 


‘PLus’, 
_ Consider an example of a control structure which contains past aa contro! 


structures, and which can be used to iustrate the construction ot me sucetrur ta 


relation: 


Example 2,1. (CA BY*10190)*/024(0/03 ED)" 


vie 


Notice that this control structure contains fous ‘basic control structures, A B, Cc, D 


i+ 


and E. The initiating events for these mene ca’s are as s specified in " Figure 2. 6. 


Fig. 2.6. Initiating events for Example 2.1, _ 


ard 
ver Fs 


The matrix | is formed following Algorithm 2.1, and it appears In Figure 2.6. 
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1. AB has no initiating event, so row 1 = = [0 000] 


2. C’s initiating event is ei. The control sttuctuce ici e1 
is (A B)*, which contains the basic.cs A B. Thus:I[2,1] := 


3. D’s initiating event is e2. The. control structure preceding e2 
Is ((A B)*/e1)C)* which contains the basic cs’s A B and C. Thus 
[3,1] := 1 and [3,2] := 1. 


4. E's initiating event is e3. The. control structure preceding e3 
is D. Thus (4,3] := 1. 


Fig. 2.6. The ! matrix for Example 2.1. 


Now, to get the overall preemption structure, compute 1+, the transitive closure 


of |, as shown in Figure 2.7. 


Fig. 2.7. + for Example 2.1. 


The preemption relations of the control. etructure are summarized In Figure 2.8. 
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Fig. 2.8. Preemption structure for Example 2.1, 


2.6.3: Occurrence of Events . 

The notion of an event “happening” la purposefully left vague; each applica- 
tion of the notation can attach its own meaning. For the purpose at hand it is 
sufficient to assume that an event variable is like a flag win gets set when its 
associated event occurs. The processor checks all ‘the event variables before be- 
ginning execution. of every instruction.. The following informally describes what hap- 


pens if any flag is found to be set: 


1. In the case where LC is to the right of the event variable 
which has been set, no Immediate effect on execution of the 
currently running task resulte. The cugrently.ruhning task is of a 
higher priority than that which Is requesting ‘the interrupt, 

i 
2. The event variable ‘remairis set until auth ‘time as LC is to the 
left of it and in a basic cs ‘which is peoemptite by It, at which 
time It will cause a presmption. 
3. {If more than one event eae to ‘event variables to 
the right of LC has happened, then the rightmost one represents 
the highest priority intercupt (request). .and LC: moves'to the right - 


1. Generally, a queue of requests is associated with a given event variable, so 
that additional occurrences of the event will be remembered if they occur before 
the Initial occurrence is noted by the processor, By specifying a length for this 
queue, a system which remembers an arbitrary number of event occurrences can 
be modelied. 
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of it (assuming, of course, that LC was within a basic cs preempti- 
ble by the event). 


4. Compietion of the control structure at a given priority "resets" 
the event variable which triggered its execution; note that this 
must be done at completion rather than at initiation so that if the 
control structure is preempted before it completes, then LC will 


return to it when it is once again the highest priority control 
structure requesting processor service. 


2.6.4: Substructure at a Single Priority Level 

A useful extension to the scheme is to provide for arbitrarily many control 
structures! to reside at the same priority level, but to be initiated by different 
events. During execution of one of these control structures, occurrence of events 
in the other(s) at the same priority level! will have no (preemptive) effect. The 


principle syntactic change is to allow replacement of an event variable by an event 


coupled list, as shown in Figure 2.9. 


<preemptible cs> ::= <control structure> / <event list> 
<event list> ::= <event var> | (<event coupled list>) | 
(<event coupled list>)* 
<event coupled list> ::= <event var>: <control structure> | 
<event coupled list> ‘[ <event var>: <control structure> 
where ‘[ means the terminal symbol |. 


Fig. 2.9. Syntax for event coupled preemptible control structures. 


1. Of arbitrary complexity, e.g. there may be additional local priority structure. 
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Consider an exampie: 
(A*/(e1: B | .e2: C)}* 


Preemption rights are as follows: 


LC at | Preemptible b 


B . 
Cc 


Execution of B or C continues uninterrupted to termination. Termination of B or C 
returns LC to A (unless e1 or e2 has happened ag#in). 
A slight modification in the position of the terminal *” leaves the interrupt struc- 


ture the same but resuits-in different behavior on tefiination of B or C: 
(A*®/(e1: B je2: C)*) 
The Idea here is that once either B or C has been initiated (through occurrence of 


e1 or e2, respectively), contro! Is never again returned to A. Instead, B and C will 


be executed every time e1 or e2 occurs. 


2.6.5: Determining the Interrupt Structure 

Since arbitrary control structures. may reside In.an event.coupled list, it follows 
that such structures may contain additional, events {or event coupled liste} .which 
trigger even more deeply nested control structures. 

This ability to nest control structures raises a new semantic issue; what 
should be the scope of events which area: fot-at the top. ievel inthe event’ coupled | 


list? The choice made here Is to let any event In an event coupled list have the 
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same scope external to the event coupled list that an event variable would have if 


it were substituted for the event coupled list. Consider the following: 
Example 2,2. (A/(e1:((B/e2)C)je3:((D/e4)E)))* 


The scope of e1, e2, e3 and e4 external to the event coupled list 


(e1:((B/e2)C)|e3:((D/e4)E)) is the same as that of eS in: 
(A/e5) 


namely, the control structure to the left of the slash in the construction "/(<event 
coupled list>)". 

The initiating events, as shown In Figure 2.10, are determined as before: the 
first event variable to the left of each basic cs. The internal scope of the event 
variables is somewhat different, though. Events in event coupled lists may not 
preempt any task in the [lst which Is separated from the event by a "|". Thus in 
the above example, e3 and e4 may not preempt B or C. Therefore Algorithm 2.1 


must be modified to reflect this. Figure 2.11 shows the resulting algorithm. 


Basic cs | Initiating event 


Hi z 


Fig. 2,10. Initiating events for Example 2.2. 
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Algorithm 2.2: 


1. Let na be the number of basic cs’s in the control structure 
under examination. Associate a unique integer from 1 to n with 
each basic cs. 


2. initialize | to be an nxn matrix of zeroes. 
3. For each basic cs /, do stapes 4 and 5. 


4. If basic cs / has no initiating event, leave row / of f equal to. 
all zeroes. 


§&. ff basic cs i has an initiating event e, then this event appears 
In either a "/e" construction or a “je" construction. 


a. If e@ appears in a “/e" construction, call the 
control structure Immediately preceding "/e" 
“control structure k." For each basic cs / in con 
trol structure k, set i[/,/] equal to 1. 


b. If @ appears in a “je" coristruction, then e 
cannot preempt any other basic cs’s in the 
event coupted list of which ft Ie a member. Its 
scope starts at the control structure to the left 
of the */" in the construction */(<event coupled 
list>)". This will be the control structure 
preceding the first unmatclied feft parenthesis 
to the left of e. Call this “contro structure k." 
For each basic cs Jj In controf structure k, set 
Ki,f] equal to 1. 


Fig. 2.11. Computing | for cs’s containing event coupled fists. 


The control structure of Example 2.2 has the following preemption relatiorr 
ships: . 
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Since two or more tasks may reside at the same priority level, such as B and C 
above, a natural question arises; what happens if both e1, and 88 occur. “simultane-. 
ously," at least within the resolution of the Interrupt system. 1 Most systems, adopt. 
some arbitrary metric to resolve rach situations. A typical one Is the distance. of. 
the interrupting device from the CPU. A net approach Js. taken here. If more 
“than: one event is found to have occurred at the. same Priority level, then control is.. 
sebitearity given to the first ottmost) « one in the event coupled ist. 

However, with the addition of event coupled ists, forks" are introduced Into 
the preemption structure, a as shown in Figure 2. 12. A diagram guch . as this is called. 
a Control Flow Graph, and will be defined formally and used extensively in the next 
chapter, For now it is sufficient to note that ans diagram unravels” the preemp- | 
tion structure so that the relative priority sevele of each tank are ceeye’: If two 
or more events happen together, priority is ‘iven to the event which initiates the 
task having higher priority, as was “done before. ‘in the anaue example, if el and 


x 


e4 happen simultaneously control is given first toE (which “A initiates). 


ne: 2.12. cleenp tion: siuctire for Example 2.2. 
1. Typically the presence of interrupt vamiouts will be | checked for once per in. 


struction cycle, soahy interripts happening bétween two Buch chécks will be indis- 
tinguishable as to their ordering in time. iy ee 
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2.7: Non-preemptibie Tasks 

it Is occasionally necessary to perform ail oe ome subset « of a control structure's 
tasks in a nompreemptible mode, even though in the latter case other tasks at that, 
priority level may be preemptidie. Simply indicating that a task is non presse tie 
is equivalent to saying that the interrupt system is “tumed off" while that task is 
In execution. For generality, the notation atlows as an ‘gitemative the specification 
of exactly those events which are not allowed to interiigt the sak Both repel: 
tles are provided with the augmented syntax, shown in Figure 2. 18. The scope of 
the symbol for non-preemptibitity extends to closed control structures In the natural 


way, l.e. every task in the closed cs Is Acar praomctbre. 


<basic cs> ::= <task> j <basic cs>  <task> 

<task> ::= <task Iid> | <non-preemptibie tid> 

<nor-preemptible tid> ::= *<task> | “(sev list>)<task> 

<ev list? ::= <event var> | <ev list>,<event var> 

<non-preemptibie closed cs> ::= *<closed cs> | *(<ev list>)<closed cs> 
<closed cs> ::= ...(same as before pits: )... | <non-preemptibie closed cs> 


Fig. 2.13. Syntax for non-preemptibie tasks. 


Prefixing a task Id (or a closed cs) with an ‘apostrophe (e.g. ‘A) indicates that that 
task is not preemptible by any event. if there is an event pet after the apostrophe 
(e.g. *(@1)A), then that task is not preemptible by any event in the event list. 
Furthermore, it is not preemptible by any event.which coult. lead. to siesctnaty 


an event in the event fist. For example: 
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(((((A*/e1)(e3)B C)/e2)D/e3)E)* 


Here if LC is at B, it is not preemptibie by e3 or e2, since e2 initiates D which /s 
preemptibie by e3. _ 

Algorithm 2.2 can still be used to determine the nominal preemption structure 
for the control structure’s set of basic cs’s. However, the output of Algorithm 2.2 


must then be modified by removing preemptibility relations as specified. 


2.8: Stopping the Flow of Control! 
Although the emphasis has been on how LC moves within a control structure, 
there may well be times when there Is simply nd work ‘to ‘be ‘done for the moment. 
itis worth pointing out how the existing notation’ indicates this with some exam- 
pies. 
Basically LC will halt when It elther: 


1. Reaches the "end" of a contro! structure, and finds no ‘or 
2. Reaches a slash (Pf) beyond which no events (which are ca- 


pable of interrupting the control structure to the left of the slash) 
have occurred. : 


Several examples are given in Figure 2.14 to clarify this concept; for conciseness, 
a typical (but not unique) task string which.may.be g@nerated by each control 


structure is given. Additional notation should be self-explanatory. 
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((A*/e1)B)* ——> AAAa1TBAAAE1B... 
((A/e1)B)* —-> A (wait) @1 BA (walt) 01 B ... 
((A*/e1)B) —-> AAAet1 B (halt) 


(((A*/e1)B)/e2)"*  -—> AAAe1 B (walt) e2 AAA... 


Fig. 2.14. Exampies of processor Idling. 


2.8.1: Breaks in Event Coupled Lists 

In light of the interpretation given to construets. which result in stopping the 
flow of control, it will be nated that there is no way to apply iteration to a portion 
of the control structure which includes all of a lower:prierity contro! structure and 
part of an event coupled list. What js needed ja the concept of a break, which is 
essentially a restricted “go to" statement; It directs LC to jump over the rest of 
the event coupted list to the right carenthosis matching the initial left parenthesis 
of the event coupled list. Thus it enables the iteration at the end of the event 
coupled list to be applied to any intermediate part of the list as needed. The syn- 
tax for a break is the up-arrow (T) at the point where the break is desired; it ak 


ways follows a basic control structure, so It can be incorporated Into that BNF: 
<basic cs> ::= <task> | <basic cs> § Ctask> | <basi¢ cs> tT 


As an example, consider the control structure of Example 2.2 modified to include 


two breaks: 


(A/(o1 :((Bt/e2)C)je3:((0t/e4)E)))* 
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Now, when LC reaches the end of B or D, It returns to A instead of waiting for e2 


or e4, respectively. 


2.9: External Termination of a Control Structure 


Consider the control structure: 
Example 2.3. ((((A*/e1)B*)/e2)C)* 


Since B* Is non-terminating and runs at a higher priority than A*, A will never be ex- 
ecuted again once e1 occurs. | There is nothing wrong with this per se, but with 
the given notation it is not possible to- represent the case where occurrence of e2 
aborts the repetition of B, and returns control to A* after executing C rather than 

To do this, the notation must be able to Indicate that occurrence of an event 
terminates execution of a particular control structure, and thus LC does not return 
to that control structure until its initiating event occurs again. The modified syn- 


tax: 


<task> ::= <task id> | <non-preemptible tid> | <abort tid> 
<abort tid> ::= @<task> | @(<ev list>)<task> 
<abort cs> ::= @<closed cs> | @(<ev Iist>)<closed cs> 


<closed cs> ::= ...(same as before plus: )... | <abort cs> 


Thus it can be specified that any event aborts a task (e.g. @B) or set of tasks 


1. Regal, that an event "flag," in this case @1, Is pet turned off until the end of 
the control structure which its occurrence Initiates. B* has no end. 
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(e.g. @(A'B C)) or that any set of events causes termination (e.g. @(e238). The 
event which aborts the task(s) need not be the same as the one which causes 
preemption in a particular case; execution is terminated as long as the aborting 
event occurs sometime after preemption and perce Lc returns to the task. 

If the control structure of exami 2.3 is changed to make B an <abort tid>, 


the desired behavior is obtained: 
((((A*/@1)@(02)B*)/e2)C)* 


Now the string ‘A A Ae18BBBa2C AAA...” can be generated, where repetition 


of A and B is for an arbitrary: number of times. 


2.10: Return of Contro! to a Preempted Task 

There are two distinct choices of what to do when LC big to a task which 
was interrupted dung its execution: elther resume excculn, om where it left 
off, or start over again from the beginning of the ) task. These two strategies will 
be fatarvedl to as resumption and restarting respectively: Each strategy has its 
advantages and may be the best choice in different situations. A task which is ‘ne 
terrupted often enough may never complete if it is always restarted from the begin 
ning. On the other hand, in a process control situation the inputs to an interrupted 
task may have changed radically since it was preempted, “and resuming the compu- 
tation started with the “old inputs may ‘lead to ‘anachronistic outputs which are not 
relevant to the current. control situation: Therefore, it Is desirable to liicorporate 
means of representing both strategies in ‘the notation. For complete generaitty, it : 


must be capabie of handling a situation where two different tasks In the same con- 
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trol structure may follow the two different strategies. Furthermore, it is necessary 
to remember the point of interruption in the case of resumption, so the processor 
will know where to resume execution. 

When the problem of restarting a control structure Is examined carefully, it is 
seen that there are really two sub-cases which are of interest. First it must be 
recognized that the actual unit which is restarted is the task. At the next higher 
level, a task appears in a control structure as part of a basic control structure. 
Thus the problem Js really how to ‘estar a <basic cs>. If there is only one task in 
the <basic cs>, the problem is easily solved-simply restart that task. If there is 
more than one task In the <basic cs>, then the entire <basic cs> could be restart- 
ed from the beginning of Its first task, or it could be restarted from the beginning 
of the task which was partially finished when the preemption occurred. For oe 


ple, consider the following contro! structure: 


(((A B)*/e1)Cc D)* 


if event e1 occurs, and C D executes, (A B)* must be restarted (or resumed). 


Here are the possibilities: 


1. Resume from the point of interruption, in either A or B. 
2. Restart from the beginning of A. 
3. Restart at the beginning of A if LC was at A when e1 oc- 


curred; restart at the beginning of B if LC was at B when e71 oc- 
' curred, 


The first case will be the default case, and 's assumed for all basic control struc- 


tures as they have been so far defined. The second case will be called g/oba/ 
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restart; the third case focal restart. if a seyrtax. ie -defitied for the concept of gic 
bal restart, It can be. used to synthesize local restart as ‘a ‘especial case. Thus a 
syntax will be given called “restart cs", and it: wi have-semantics of “giobal res- 


tart", the second case above. 
<restart cs> ::< > <basic ca> 


To contro! the scope of the rectart symbol, restart control structures are intro- 
duced Into other control structines pani through their appearance In | closed con 


trol structures: 


<closed cs> ::= ( <basic cs> ) | ( <preemptible ca> ) | 
( <closed cs> <preemptible cs> ) | ( <closed cs> <basic ca> ) | 
( <closed cs fist> ) | ( <restart cs> ) 


Here Is an example of a contro! structure containing restarts: 


(COA BAC DKOEIOF)))/e 1)4)* 


Executien of this. control structure proceeds identically to that of the basic control 
structure (A B C D E F) until event eft happens. This causes: execution of G; after 


G completes: 


1. If LC was at A or B when e1 -happened, LC returns to the be- 
ginning of A (global restart of (>A B)). 


2. if Le was at C or D when 61 ‘csadaa’ 10 ranulas How te 
point of interruption In either C or D. 


3. If LC was at E or F when e1 happened, LC returns to the be- 
ginning of E or F respectively (note that local restart of (E F) Is 
equivaient to ((>E)0>F))). 
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2.10.1: Conditional Restart of a Control Structure 

There is another possibility which should be represented. !n some instances, a 
task should be restarted if it was preempted by one event (or one of a set of 
events), but resumed if It was preempted by another. This is handled by explicitly 
listing the events which would cause restart of a task. Thus a restart cs without 
an event list is unconditionally restarted, while one with an event list is only res- 


tarted if an event in its event list occurred since it was fast run.! 


<restart cs> ::= > <basic cs> | > (<ev list>) <basic cs> 
Example: 
(((((>(e2)A)*/e1)0B))*/a2)C)* 
Here A is restarted If elther 


1. Ais preempted by e2 or 


2. A \s preempted by e1, which starts B. B is then preempted by 
e2 before completion. 


B is unconditionally restarted, and A is resumed if e2 does not occur between the 


time of A’s preemption by e1 and the resumption of A. 


1. Note that this means that the restart causing event need not be the one which 
caused the task’s preemption; there may have been a chain of preemptions which 
included the restart causing event, and this Is deemed sufficient cause for restart. 
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2.11: Codestripping 

A time-sliced allocation of processor time can be represented with the existing 
notation by letting the event Variables aad for timer-generated interrupts. One 
additional form of preemption which will be explicitly represented here is codestrip- 
ping, as outlined in Section 1.1. | 

In codestripping, calls to the operating system are inserted Into a task by the 
compiler at calculated intervals, resulting In pieemption of the task when they are 


executed. The syntax is as follows: 


<codestripped cs> ::= <basic cs> / <intager> 


<preemptible cs> ::= <control structure> / <event Hst> | <codestripped cs> 


Thus codestripped control structures are introduced Into other control structures 
under the same syntax as preemptible control structures. An example of a codes- 


tripped contro] structure: 
((A B/6)C)* 


The meaning here Is that the basic contro! structure A B is executed 1/6 at a time, 
based. on its totat (estimated) execution time; it is then preempted and C is exe- 
cuted. When C finishes, LC returns to the point of preemption, and executes 
another 1/5 of the way through A B (whether this Is actually In A or in B depends 
of course on thelr relative lengths). Thus C will be executed five times for every 
single execution of A B. 

Notice that control structures such as OA B/10) are syntactically Illegal; the 
notion of globally restarting (or locafly restarting, for that matter) A B is incompatt 
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ble with the semantics of codestripping. Furthermore, codestripping of closed con- 
trol structures could Jead to highly ambiguous or meaningless structures and is 
disallowed. This prevents such structures as ((A B/5)/10) and (((A B*/e1)C)/5). 
Structures which execute until they elther finish a codestrip or are Interrupted by 
an event are allowed, as they should be, e.g. (((A B/5)/e1)C)* which executes C 


for every 1/5 of A B executed and whenever e1 happens. 


3; Representational Power of the Notation 


3.1: Introduction 

This chapter presents a catalog of control structure types which the notation: 
of the preceding chapter is capable of representing. it is not claimed that every 
conceivable type of representable control structure is included, but the list at- 
tempts to be comprehensive as to general forms. Some examples are also given of 


types of control structures which are not representabie. 


3.2: Cantrol Flow Graphs 

Control structures can be conveniently categorized by the topology of their 
Control Flow Graphs, or CFG’s. A CFG is a directed graph; more precisely, it is a 
set of nodes and directed arcs, where a node represents a basic cs and an arc 
represents the movement of LC between two nodes. The nodes bear the names of 
the basic cs’s which they represent. 

Consider an arc A which originates at basic cs o and has as a destination 
basic cs d. If o occurs to the left of d in the control structure, then arc A is a 
forward arc; otherwise, it Is a backward or back arc. Elther type of arc may bear 


labels: 


1. An arc which represents the uninterrupted flow of contro! due 
to termination of a basic cs is a forward arc, and ts unlabelled. 
Note that this includes breaks as detailed in Section 2.38.1. 


2. An arc which represents the flow of contro! due to preemption 
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by an event occurring is a forward arc (an event arc) and is la- 
belled with the corresponding event variable. 


3. An arc which represents the flow of control due to iteration is 
a@ back arc and Is labelled with an "*", 


It may seem that tasks rather than basic cs’s should be at the nodes of CFG’s, 
and in fact the algorithms used for determining real-time latencies must sometimes 
deai with control flow at the task level. However, this additional detail adds noth- 
ing to the breadth of representable control structure types, and in fact detracts 
from the readability of the CF@’s.' 


Figure 3.1 gives an example of the CFG for a simple control structure. 


AB 


e1——>C 


Fig. 3.1. CFG for ((A B)/e1)C)*. 
A string naming the tasks and (optionally) the events encountered in a path taken 
by LC through a CFG is called an execution of the corresponding control structure. 


ABe1l1CAB andAe1CAel C are both executions of the above cs. 


1. lf, for example, a basic cs is preemptible by event e/, then every task in the 
basic cs would have a forward arc labelled e/. 
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3.2.1: Priority Levels 
As an extra benefit, the CFG notation provides a convenient mechanism for for- 
malizing the concept of priority level, which has been used somewhat intuitively 


thus far. To find the priority level of basic cs./, do the following:. 


1. Let the leftmost basic os in the contro! stricture have priority 
0 by definition. 


2. Find the acyclic path from the priority. 0 peslc, cs to basic esi 
having the jargest number of event arcs. 


3. The priority of basic cs / is equal to the number of event arcs 
in this path. 


3.3: Interrupt Driven Control Structures 

The CFG’s for control structures using only sequencing and iteration are fairly 
straightforward and do not expand the cataiog of representable contro! structures 
by much. The sequence of tasks within a basic cs Is eave represented, and 
forward control flow from one basic ¢ cs fo another simply ‘translates to an anabolic 
arc in the CFG. ~ 

‘The moré interesting CFG’s are those which are derived froin control structures 
having event variables. It Is readily apparent that ‘the qotation has considerably 
more flexibility than that which is needed for representing traditional priority inter- 
rupt schemes. This flexibility is derived principally through the placement of the 
"2" Iteration character and by use of the branching introduced by event coupled 
lists. The latter has been mentioned briefty; the former bears clarification. 


A back arc can be originated from any basic cs by following it with an "**, 


Interrupt Driven Control Structures Section 3.3 


However, there Is a degree of freadom in specifying the destination of the back 
arc; this will be exercised in enlarging the catalog ef contro! structures. Funde- 
mentally, the back arc may return to the same priority level, a fower one,’ or the 
lowest one. If it does not return to the west revel a certain "shrinkage" in the 
future range of LC is experienced. “This will be sisborated on shortly. Additional 
variations: on the fundaniental types are achieved through-tise of the Interrupt mask 


(mor-preemptibie tid), external abort and restart/résumd' capabilities. 


3.3.1: Globally Cyne: Control Structures 

. Under this aatenory is Included all ‘control structures -_ CFG’s such that 
every back arc, regardiess of its odigihating Siteriey: ‘evel goes to the first task of 
the lowest priority level. informally, this means that upon completion of the tasks 
at a given priority level, the processor will scan all the event variables In the con 
trol structure from the lowest level to the highest, and begin execution of the 
highest level task pending. This is as opposed to control structures with local cy- 
cles, where the lower priority Scanks are not ekeataiy considered in each such 
situation. 

The traditional interrupt systems. available’ on most’ processors fall into this 
category; such systems. are: further subdWwided' Into two types, Which are called 
here the weak priority system and the strong priority system. In the weak priority 
system, although arbitration between interrupts from two or tore events Is provid- 
ed, there Is actually only @ alngia true levet-of interruption. There is a “user" or 


"main" program which runs at the lower priority, and any number of events may 
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each preempt it; however, no event may interrupt. any task. which gained control:it- 
self via an Interrupt. .This type of control structwe is: represented using event 


coupled fists, asin Example 3.1. 
Example 3.1. (MAIN/(e1: Ale2: Bje3: C))* 


The CFG (Figure 3.2) has an interrupt branch from “main" for every interrupting 
event, to the basic cs it initates. Completion ofA, Bor C. forces LC to return: to. 
_ MAIN, so there is a back arc from each of them. For the sake of keeping the CFG’s 
readable, multiple back arcs with the same eee wil sie enemmed: as is 
done in Figure 3.2. {t ts worth Keening in sind. however, ‘that this does nat imply 


that another type of node Gunetion) hee ‘been added. 


Fig. 3.2. CFG. for Example 3.1. 

_ A strong priority system. supparts a processor: pricsity; the. currently running 
task has a priority 2 associated with It, and- any events interrupting with priority m 
> a may preempt it. With the exception of: the abiltty provided for masking inter- 
rupts, the processor runs the highest prierity task .walting for service at any time. 
This type of multiple priority level interrupt system. is repreaanted by strict nesting 
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of preemptible (and Iterative) control structures, as shown in Example 3.2. 
Example 3.2. ((((A*/e1)B)*/e2)C)* 


The general form can be recursively constructed; each “layer" looks like: 
((<iterative cs>/<event var>)<basic cs>)*® 


which is itself an iterative cs. The <basic cs> runs at the. next higher priority than 
, the rightmost basic cs in the <preemptible cs>. 
A CFG for Example 3.2 Is given in Figure 3.3; it can be seen that the proper- 


ties of nested Interrupt systems have natural analogues in the graph: 


1. Let @ and 8 be basic cs’s in the CFG. If there is an acyclic 
path from a to 8 whose last arc is labelled e/, then there is an 
arc from @ to # labelled e/. This property : stems. from: the trans- 
tivity of interruption In a nested, “multiple. priority system. 


2. There is a back arc from the last basic cs at each priority lev- 
el to the beginning of the lowest pricety basic.cs. After comple- 
tion of the contro! structure at a given priority level, LC returns to 
the highest level with a pending request. 


. Te iis ee OS 
ae 


Fig. 3.3. CFG for Example 3.2. 
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3.3.2: Acyclic Control Structures 

At the other end of the spectrum are found Control structures with no back 
arcs; these represent completely non iterative “eysteea where the flow of control 
terminates when It reaches the end of any path: Such-contral structures are furth- 


er subdivided into two types: | 


1. Linear contro! structures - control flow is straight-line and thus 
entirely predetermined, as in the example of Figure 3.4. 


2. Branched control structurés - realtime’ decisions based on 


event occurrences determine the sctual flow of control; see Fig 
ure 3.6., which provides ari ae 


The subject of linear control structures does ime leave much room for discussion 
and is included mainly for completeness. However, there ere soma interesting ob- 
servations that can be made about branched contro! structures representable with 
the notation, and which apply independently of whether thare are cycles present; 


these will be considered in the following section. 


A——_—e1——__»B C——_5D 


Fig. 3.4. CFG for the control structure ((A/o1 XB C)D). 
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et —> Bn - 
Log OP 


Soe 


Fig. 3.5. CFG for the contro! structure (A/(e1:(B/(e2:Cje3:D))|e4:E)). 


3.3.2.1: Branched Control Structures 

It Is Interesting to note that while tree-shaped CFG’s such as the one In Figure 
3.6 can be represented, allowing arbitrary tree-shaped interrupt structures is not 
compatible with the transitivity of eiterunition: | In fact, the notation cannot 
represent any tree of depth greater than one -whare the forward arcs are all event 
arcs. Thus a CFG such as the one in Figure 3.7 has no sceeanondwia control struc- 


ture. 


e1—>B 


we 
erie 


Fig. 3.6. A tree-shaped CFG, for (A/(e1:Bje2:C)). 
For example, consider an attempt to derive a control structure for the CFG in 
Figure 3.7, a tree with a depth of 2. By Algorithm 2.2, It is found that since C in- 


terrupts B and B interrupts A, C must also Interrupt A. Thus an arc labelled e2 
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must be added from A to C, end the tree structure Is lost. Event e2 (and e3) can 
be masked from interrupting A; but then-e1 Waite masked, since it initistes B 
which Is interruptible by e2. This. same fine of reasoning applies to any other at- 
tempt to produce a tree-shaped contro! atrueturesdf depth greater than 1. 


A——#1 


os 


Fig. 3.7. A CFG which has no corresponding control structure. 
Easentialy, this restriction says that there cannot be control structures which 
have completely jocal preemption structures, and yet at the seme time be initiated 
by some event. To incorporate this type of structure would require « notion of “lo- 
cal" and "global" events, with suitable restrictions on their scope. The additional 
complexity this would introduce may be Incompatible with the attempt to keep the 
notation concise, but this may be a logical extension of the language for some ap- 
Atthough ft does not represent « preemption structure, Figure 3.8 shows a CFG 
which is similar to that of Figure 3.7, but which /s representable, and by the foliow- 


CA were Jez: >» 


The arc from A to 8 represents cont fow on termination of A but A cannot be he 


bag 


terrupted. 
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e2———>C 


a 


‘e3-—>D 


Fig. 3.8. A representable tree-shaped CFG. 


3.3.3: Locally Cyclic Contrel Structures 

Included In this class are all those: control structures having back arcs which 
do not return LC to the lowest priority level task. This group Is further subdivided 
into structures. which never return control ta. the lowest priority task, and those 
which may or may not make the return at some’polnt. White‘the emphasis: here is’ 
on returning to the /owest priority level, the same sort of distinctions can be made 


about any priority level and its superiors. Examples of each case will be given. 


3.3.3.1: Dynamically Decreasing the Range of LC 


Consider the following genera! form of control structure: 
Example 3.3. (... <preemptible cs><closed cs>*/<event var> ... )* 


This has a nor-terminating "<closed cs>*" construction, which corresponds to a 
back arc In the CFG from the end to the beginning of the closed cs. Although the 
rightmost "*" forces LC to return to the beginning of the control structure (if the 


"2" is reached), the <preemptible cs> will not be resumed since the following 
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<closed cs> runs at a higher priority, and Is nor-terminating. 
Figure 3.9 gives the CFG for the control structure: 


Example 3.4. (((A/e1XB €)*/e2)D)* 

which has the above general form. ii canlie ceed hat Gace -ainen tonanaine Ew 
is entered, although it may be preempted by higher priority tasks (either momentari- 
fy or permanentty), control will not return to any task to: Its teft. Thus ‘tha ‘control 
structure has effectively "shrunk", in that certain taske are no tonger executable. 
This. shrinking may occur in stages, if there are severe events which initiate itera- 
tive control structures, and which occur in succession; or it may occur aff‘at once, 


Fig. 3.9. CFG for Example 3.4. 


3.2.2.2: External Termination of Local Cycies 

A local cycle need not always indicate a decreasing control structure. Af the. 
aG ces hase) cance cctalus Gaius tnais cuearcl may veoule Ra a erty ae 
time in a given sub-structure (local cycie), and finally return to lower priority ievels 


External Termination of Local Cycles Section 3.3.3.2 


when the aborting event occurs. The contro! strueture of Example 3.4 can be 


modified by the addition of a single “@" symbol: 
Example 3.5. (((A/e1)@(B C)*/e2)D)* 


Now when e2 occurs, it "shuts off".e1 as well as initiating D. This is a dynamic 
behavior and as such Is not well suited to representation by a CFG; however the 


reaktime latency algorithms must certainly take account of It. 


3.3.3.3: Restrictions on Local Cycles 

_ A back arc can be. formed fromthe. end to the begining of any closed control 
structure, and hence.therg Is: litte restriction on its range of possible destinations. 
One notable exception. occurs in the presence of event coupled lists. Figure 3.10 
gives a CFG which does not have a corresponding control structure; its Ilegality is 
the presence of a back arc which cuts across the “(":syntactic boundary in an 


event coupled list. 


1 
et 


e2 


Fig. 3.10, CFG with an iiegal back arc. 
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Essentially, this says that the forking caused by event coupted fists forms two 
or more independent sub-contro! structures, and LG cannot move freely from one to 
the other. However, it fs possible that an event external to all the branches may 
preempt any of them; thus a CFG identical to that of Figure 3.10, except that it 


has no back arc, corresponds to the legal contro! structure: 


(((A/(e1: Bje2: C))/e3)D) : 


3.4: CFGs at the Task Level 

There are several variations on the general classifiéations presented here 
which arise principally when control flow at the: intertask tevel Is considered. As 
previously mentioned, the complexity of the resulting CFG’s limits their usefulness. 
Thus these variations are more suitably discussed In the context of tatency afgo- 
rithms; furthermore, they do not introduce new general clesses ‘of controf structure 
types as far as the topology of their CFGs Is concerned, but Instead résutt tn per 
turbations of those already considered. 

However, It is reasonable to examine the changes which. would be induced ona 
CFG which has single tasks at Its nodes, rather than basic cs’s. Use of the “<non- 
preemptible closed cs>" or "*<non-preemptible tia" constructions results In the re- 
moval of the appropriate event arcs. in addition, if the ‘tak immediately prior to 
the "/<event var>" ctideitruction is masked, an unlabelied forward arc is added to 
show the flow of contro! which occurs on termination of the masked task. 


The default mode of control return to a preempted task is resumption, as dis- 
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cussed In Chapter 2. Thus any arc (backward or forward) to a preemptibie cs of 
this type must be dynamically relocated ‘to. peint to the task which was in execu- 
tion when preemption occurred. Agaln, this is not easily representable with a static 
CFG, and in fact corresponds to the need to store some "state" information while a 
task is dormant. 

If a task Is to be restarted, this problem does not arise; in fact, if an entire 
closed cs Is of restart type, there will be no arcs pointing to tasks internal to the 
closed cs which originate outside of it. The only entry point from the external 


world’s point of view is the beginning of the Initial task. 


4: Reattime Properties. of Control Structures 


4.1: Introduction 

A primary motivation behind developing the language presenta in Chapter 2 is 
to provide a representation of control structures ‘suitable for use as an analytical 
tool. Specifically, it provides a convenient format for ceveyind preemption and 
control flow information to an algorithm which then determines reattime properties 
of the given contro! structure. | — | 

The algorithms to be given here are not intended to provide an exhaustive 
analysis of a control structure, but rather to be representative of the types of 
analysis which may be performed. The realtime properties measured here are of 
common interest; however, It will probably be the case that, depending on the 
needs of the particular user, different realtime properties may be of special in- 
terest. in many cases, the given algorithms can be adapted for measuring different 
intervals with minimal changes. in other cases totally new algorithms may be need- 
ed, but parts of those given will still be useful. 

Much of the terminology used here was developed in [Teixeira 78] and the 
reader is referred there for a complete discussion. 

A principal goal here will be to develop aigorithms for determining the worst 
case latency of a list of tasks in a given control structure. Iinformalty, the worst 
case latency of a list of tasks « (written I(x)) is the longest time that can elapse 


without there being a complete execution of each task in the list in the order 
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given. The list of tasks whose latency is being measured will be referred to as a 
constraint. The latency of a constraint is measured with respect to an execution 
of a given control structure, where an execution is a list of tasks in the order in 
which they are executed by the CPU in a particular invocation of that control 
structure. Each element (task id) of the execution has a weight associated with 
it, written as |<task id>]. The welght represents an upper bound on that task’s 
execution time on a particular processor. 

Note that depending on event timings, a number of different executions (of 
finite or infinite length) may be generated by a single control structure. Consider 


the contro! structure: 
(((A B)*/e1)C)* (5.1) 


Possible executions include: 


ABABAB... 
ABCABC... 


ABABCABABC... 


among many others. Also note that in the case of preemption a task may be 
suspended and restarted, and thus partial weighting (or Its effective equivalent) 
must be accounted for. 

The weight of a list of tasks is the sum of their Individual weights. The worst 
case fatency of a constraint a with respect to an execution 8, is the sublist of B 
with greatest weight which does not contain a. The term "contains" as used here 


means that the elements of @ occur in order and with their full weights; there may 
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be arbitrarily many other tasks interleaved. For exampie, (A B C D) contains (A C) 
as weill-as (A 8), but it does not contain (C B). 

The provision that the tasks be Included with their full weights is emphasized 
for the following reason. in many reattime process control applications, the inputs 
to a task may change at any time, but the scheduling of task Initiation may not be 
synchronized with the arrival of new inputs. Thus it Is entirely possible that new 
inputs may arrive immediately after the initiation of a task, L.e., after it has already 
read the outdated inputs. Given this possibiiity, it may be that nearly two complete 
occurrences of the constraint may be executed in ah Intérval which still does not 
contain (in the strict sense defined above) a single occurrence of the fist. For ex- 
ample, given the control structure (A B c)*, consider the execution ABC ABC. If 
an input to A arrives immediately after A fends Its old input! then it is only after 
the second occurrence of C has completed its execution that all‘the tasks In the 
constraint will have been executed in order (the constraint Is satisfied by such an 
execution). Thus a way is needed to represent an execution whose end-tasks are 
weighted just less than their nominal values; the notation chosen Is: bracketing 
such a task on its “short side"; [A means “begin just after the start of A", and C] 
means "stop just before the finish of C". The welght of such a task is Its nominal 
weight minus «, where « [s arbitrarfty smaif:. Yhus the worst case latency of (A C) in 
(AB C)* is | [ABC ABC] ]. 

The list (AB C ABC) is an example of ‘a critical window for (A C), where a 
4. Unless It Is known that the timings of such data arrivals can be synchronized 


with task initiation, it must ‘be assumed that this could occur at any time after A Is 
initiated. 
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critical window Is defined as a list « such that. «.costains.two occurrences of a 
constraint C but [«] contains no occurrences pf, C... in- many. cases the. worst case 
latency of a constraint will turn out to be the weight of,a.critical window {the most 
_ critical window). The worst case latency of a constraint. with. seepect to a control 
structure (as opposed to an execution) Is. taken, over all.the possible executions 
that may be generated by the control structure — no matter wiki thacavantininoe: 
(within specified limits), there can be no. longer laterval which does not contain the 
list. Thus part of the problem faced Js to classify the types of executions which: 
may be generated by a control structure and. narrow the.choice among them for 


of possible executions would make the problem intractable. 


4.2: Welghts of Task identifiers 

It was mentioned. briefly above that a weight is .asspciated with every task 
identifier, representing an upper bound on its execution time. Naturally this must. 
be with respect to a particular processor, but even with. this restriction there .are 
some difficulties in determining a meaningful upper bound on execution time. Aside 
from input dependent computation times, thers are processor dependent variables 
such as memory access time in a virtual storage system. The -worst case time 
wouid occur when all memory references wer to. the. slowest storage device, but . 
the probability of such a case actually occurring. may.be nearly zero. On the other. 
hand, there may be an uncomfortably jarge variance .associated with the mean ac-. 


cess time when critically time-dependent processes are invoived.. It seems then 
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that in such a case one must either arrive at a statistically reasonable upper bound 
on memory access time or change the storage allocation parameters of time deper- 
dent tasks to ensure their residence at a particular level of above (in access 
speed) of the storage hierarchy. 

if an upper bound on the execution time for a task does not exist, this would 
Imply potentially infinite worst case latencies and there would be no purpose to ap- 
plying the algorithms given here. If there is any question of the value of an upper 
bound, then it must be chosen carefufly In light of the particular application of the 
latency Information. The weight of each task will be an input to the latency algo- 
rithms along with the controf structure, and It wil be assumed that a function (table 


look-up) exists which returns this weight in response to the notation [<task id>]. 


4.3: Properties of Event Variables 
In order to arrive at worst case latency times for a‘controf structure containing 
event variables it is necessary to know something more about the timing of the 


events represented. To ilustrate, consider the control structure: 
(((A B)*/e1)C D)* (6.2) 


tf e1 never occurs, the only possible execution of this ciutiol etviicties Is (ABAB 
AB..). The latency (A B) in this case Is 2(/A|+[B]) -«, since the longest sublist 
which does not contain A B would be [A B A B]. On the other hand, if e1 occurs at 
least once every {C[+|D} seconds; then KA B) is Infinite, since the only execution 


generated is (C D C DC D ...) (ignoring possibie initial executions of A and 8). If 
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the control structure contains more event variables it may become difficult to deter- 
mine the worst case latency (the largest I(A B)) by inspection, and the need for 
additional Information about the event variables is clear. 


In particular, what Is needed is the following: 


(e;): the minimum period of event @;3 It is guaranteed 


(e;) 


1. ® min 


that e; will not occur more than once In any interval of *min 
seconds. 


2. ® max (9; ): the maximum period of event @;5 it is guaranteed 
that there will be at least one occurrence of e, in any interval of 


® max’? p seconds. 


It Is entirely plausible and indeed Ilkely that In some situations # (e;) will be 


min 
the same as ™ max'®; ). This is the case for all regularly occurring cyclic events, 


such as data sampling, processor time slicing, etc. 


In general, it is impossible to distinguish a r (e;) which is less than the pro- 


min 
cessor Instruction cycle time from an Infinitesimal one since the processor could not 
possibly respond to an event which occurred at that rate in any meaningful way. 


In fact, for a reasonable system, one would have to pick a # (e;) considerably 


min 
larger than the instruction cycle time, but the actual value will be application 
dependent. For most events of interest it will be possible to determine a reason 


ably tight r (e; ); @.g., if the event represents an !/O service request, it cannot 


min 
occur more often than some time interval dependent on the 1/O device’s maximum 
character transmission rate. 


Unfortunately, finding a good value for ¥ max) is more difficult in many cases. 
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An event often represents an exceptional condition, which may never arise in par- 
ticular executions. Fortunately, most control structures wif! not put time critical 


tasks In such a position that thelr initiation depends on #. maxt?}) ) but rather It Is 


more likety that the completion of a constraint may be pfuencad by time eet-atter 


such an event occurs; and the time fost will be 4 function. ot #,, n & ), not 
max 8] ). If a good value of # iste is not available for a partsuies: event, then 


It is more ) tkely that the Interval of interest woatd be tfie ma xitiecam time from the 


occurrence of @, to the initiation and/or completion of its essaciated control struc- 


ture, rather than the longest tine between such executions (a latency value). 


5: Algorithms 


&.1: Introduction 

A series of hierarchically related algorithms will be presented in this chapter, 
which will be directed at the problem of finding the worst case latency of a con 
straint with respect to a given control structure. Each algorithm in the hierarchy is 
applicable to a larger subset of the set of all representable control structures, and 
may call upon the algorithms designed for solution of the problem on a lesser sub- 
set as subroutines. 

The overhead due to context switching is not explicitly taken into considera- 
tion here. It may be accounted for by a fractional reduction of the effective pro- 
cessing power of the CPU, when computing the worst case task weights. If this Is 
not satisfactory, then the algorithms could be adjusted so that each event oc- 
currence and corresponding initiation Is counted, and the overhead due to each 
could be added to the delays attributed to interruption. 

As the worst case latency algorithms are developed, it will be seen that the 
determination of algorithms to measure several other real-time properties, Interest- 
Ing in thelr own right, Is required. Finally, special cases may result in substantial 


simplification to the algorithms, and examples of this effect are included. 
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6.2: Latencles In the Absence of Preemption 
‘The first step taken here toward the general solution of the dost base later 
cy problem is the development of algorithms to determine the latencies when no 
preemption is present, |.e. when there are no event variables or codestrips in the 
control structure. This leaves control structures which generate. finite. and. infinite 
lists of tasks, in which all tasks execute to completion.once initiated. 

Since only norterminating iteration Is represented Gn the absence of preemp- 
tion), all finite lists must contain no iterative components. Furthermore, any finite 
list L of tasks which contains at least one occurrence of a constraint ro may be 


broken down Into a series of possibly overlapping sublists: 
(ccc, or | (6.1) 


with respect to a.constraint C where: 


4. By and #, each contain one instance of C, but #4] and TP, 
contain no inatances of C. : 


2. The «,’s are critical windows far 'C.: 

The sublist B, is the head of the Hst L having minimum ec and which also 
contains one instance of C; By Is the tall with least weight which contains one Ine 
stance of C. The list «, is the critical window which starts at the firet instance in 
1. of the first task in C; «; ts the critical window which starts at the /th instance 
in L of the first task in C. If L contains no critical window, there will be no «,°8; 


1. If L does not contain C, then the latency of C in L is infinite. 
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similarly, if L begins or ends with a critical window. then B, or a, respectively may 


also be empty. 
Figure 5.1 gives an example of the breakdown for the: Hea (A B Cc DBCBCE) 


and the constraint (B C). Note the sagas les of isa — and that in this 


case |a,| # eo). 


A B Cc D B Cc BS “Lf. Ee 
/+—_—_—— e, ——_{ }—-#,——| 


Fig. 6,1. Breakdown of a finite tagk list Into sublists, 


Theorem 5.1. The jatency of a constraint C with respect to a finite list L which 
contains at least one occurrence of Cis. the. maximum. weighted sublist in 
the set of et, er otnohoh wiere:: te *; ‘* sont re are as: 


Proof. The proof will be given in two parts; first, hy showing that any list which 
contains at least one occurrence of.C can be broken, dawn in.the, abave manner to. 
obtain such a set of subfists which includes all the tasks in the original list; and. 
second, -by. showing that: no ‘other sublst: nov ity the set ean have’ sisledas apap 
for c. wintery e 


- The proof of the fwst part is given by’ stiowing @ method of sonathictinis thi 
set {6,, @ 41 Hg» ** 14 ,, Bg} given such hes eee. 


Find each sublist of L which exactly contains one ; instance of c t @., a sublist 
¥ such that 7 contains C but [y and 7] do not contain ¢); Jabel each such ayblist 
vj): for) = 4 ton, where a ‘Is ‘the number’ of instan 166 5 Of c int. “The iat L can. 


thereby pe considered as a series of sublists; i 


4: V4 +> Yor." "5 n+ Vn-1? ¢, - ; (6.2) 
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where the ¢,'s do not contain C and may be empty. If 7, overlaps 7,,,, then $,,, 
will be empty. This set of sublists includes every task in L, and with no _permute- 
tion of the original ordering. Then: 


1. A, Is 6, appended: to re 


2. «, is the list starting at 7 and : ccsuiaaaings to the and of ak : 
Including $544: Note that since vj and +1 May overlap, ‘a, Is 
not their concatenation. 


3. Bp Is Tp-1 oppended to ¢,,. 


Now for the aa Saar the worst case ateney. of Cc in L rg the maximum of 
{yb leyh legis --- + 1eyb Bold- A : 


Since the @;'s are all the critical windows in L, they represent all the lists « 


such that [«] cannot be expanded in either direction without the sesulting interval 
containing C. Simitarly, #,]'and (8, cannot be expanded | on theft’ bracketed sides 


without introducing C to the interval. Since the concatenation of 
By, @41.%m, * ++ sys Bp) contains: 1,.and. sone. of these subliéts can beexpanded 


without: the resulting subfist’ containing C, tha ‘only’ possit' Hy for the existence of a 
sublist: with: greater tatency is that:therg is such “a HSt Which Ticlides parts of two 
of the above sublists. That such a sublist with greater latency does not exist is 


demonstrated by case analysis. 


Again, consider the fist L- reorganized ‘as In equation (6. 2). Now, suppose that 
there exists a sublist § which Inciides part of A, and part of «,, and that |p] > 


Py]. and iv > Jo,|.. The. subiiet ¢ cannat. begin inid4i oF It:cauld not costain: any 
thing past 7, (without containing C) and hence |¥| < [6,|. But if starts at the 
beginning of.7,, It could incluge no. more, than.a,, and therefore Wis je,|-. 1f # be- 
gins past the beginning of-y,, it cannot: contaly arything-paat 7, and“hence |¢| < 
legl. Ths such a eupnet id does not exist. 


The same _— of renee, ‘will, show. tata subjist with. greater weight, than ; 
any of {f;, @,.°** a), 85} cannot being constructed from Parts of adjacent «,” "8, 


sbi 
ora, and 8,. Thus the worst case latency ‘of C in L wil be the maximum of (e, lL 
le, |. 2 aes |. #,). oO 5 as - i . Bong e :% 


Algorithm 5.1, FLATENCY, summarizes the procedure to be followed in finding the 


64- 


Latencies in the Absence of Preemption fe ep Section 5.2 


worst case latency of a constraint C with respect to a finite list: L. 
Algorithm 5.1. FLATENOY(L, C) eau i er 0 ee 


inputs: L, @ lst of. task. -Kdentifiers (a basle: Control. beakers ei} Is the /th task 
. in-L. 


ae? 


c, the conatraint (ele0 a lst of test Montes); en ts oe i ith task in C. 
Outputs: (KC), start index, trish Index); 
K(C) is the worst case  tateney of Ci in VL. 


start_index is the index of the first task of the sublist of L which displays 
the worst latency for C. 


finish_index Is the Index of. the last ‘teak of the ‘subliot of L which »dlaplays 


Method: 
1. Scan L to find: 


B,, the head of L with least t weight which contains c 


es i = 1 to a where n is the mabat of: occurrences of C in L 
minus 1. . 


Bo, the tall of L with least bh which contains C. 
This is accomplished a as follows. ‘All's scans  atart from the mark poll initial- 
ly L[ 1]. 


a. Reset the mark point to be the first occurrence of C[1] found 
during each scan. ao:ccoutrenos of. C£T} le: found, the mark 
point is set to the task past the one of me Cutrent scan. 


b. B, is found by seanning unt a . complete occurrence of C has 
co. The «,'s are the fists which’ exactly contain two occurrences 


of C; ae are found. by scanning. from: Ake: mark point for one oc- 
currence of C, and then scanning from the new mark point for the 
second occurrence of C. 


d. As is the result of the final scan if.no-tail of 1 is a critical win- 
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dow. 

e. If no occurrence of C is found in L, return (co, -1, -7).°- 
2. The weights of_eech.sublist are accumulated during each scan, as well 
as the start_Lindex and finish_index for that scan. At the ent# of each 
scan the weight is compared to the largest found so far, and saved as the 
new maximum. (C) .#- it. jis .greater:(In which: case. -staltindex and 
fmish_index are updated to the values for the just soapoed fist). 


3. Return the final values (AIM Heyl "> beyl, oD. 
start_index, finish_index). 


8. 3: Tatencies of costar’ in Cyctic Control _ Structures 

In the specified ‘anausee an infinite list of tasks is generated by the iteration 
construct; Iteration is elther applied to an entire control structure or to. the last 
closed control structure in a <closed cs aye Thus infinite Nats are elther entirely 


cyclic (the entire structure Is repeated): 
(ABCDE)* i (6.3) 
or have a start-up period followed by a steady state cycling: 


(AB cXD —)* (5.4) 
It would be indeed unfortunate If the entire Infinite fst had to >be examined to find 
the worst case latency, but die to the restrictions « on ite eyoue nature only a rea- 
sonably small number of cycles (to be determined) have to be.axamined to find the 
worst case. Thus the intention here is to reduce the case of an infinite list to a 
finite fst which contains the worst case, and use Algorithm 5.1, FLATENCY, on the 
result. - | | | 


The principle question Ie thus to determine how many cycles of the iterative 
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portion of the list need be appended to the non-iterative portion (if there is one) in 

order to generate a list containing the worst case latency of a specified constraint. 

First, though, It must be determined whether or not the latency is Infinite (assuming 

no task id has infinite weight). 

Lemma 5.1. Given a control structure (¢)(¥)* and a constraint C, the worst case 
latency of C in (¢)(¥)* is infinite iff C contains a task A which is not con- 
tained In ¥. 

Proof. if ¥ does not contain a task A which is In C, then (¥)* is an infinitely long 

list (and hence of infinite weight) which does not contain C, and thus in which C 

has infinite iatency. 

If ¥ does contain every task in C, then If C contains n tasks at least every n 
repetitions of ¥ contains C and hence the latency of C in (¢)(¥)* could not be 
infinite. O 
Once it has been established that the latency is not infinite, the following theorem 
can be appliled to find the sublist which contains the sublist with the worst case la- 
tency. 

Theorem 5.2. Given an iterative control structure L = (¢)(¥)* and a constraint C 
containing a task identifiers, then if the latency of C in L is not infinite, 
the list formed by appending n + 1 copies of ¥ to ¢ contains the sublist 


with the worst case latency for C in L. 


Proof. Theorem 5.1 established that the worst case latency of a constraint in a 
list of tasks was either a critical window a, or @ head or tail of the list B, or Bo. 


By Lemma 5.1, if the latency is not infinite then ¥ contains every task in C. There- 
fore 


8, & 4; ¥” (6.5) 


where ¥” means n copies of ¥ appended to each other. This is true since n copies 
of ¥ must contain C, since each ¥ contains each task identifier in C. Note that B, 


might be wholly contained in ¢, nonetheless. 
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By similar reasoning: 
o9Ftt - (6.6) 


contains the most critical window: of. (¢¥#)*; if the ‘most critical windew is con- 
tained in ¢, then equation (5.6) must contain it. Otherwise, it is contained in 
(@)(¥)*. If the most critical window starts in @ but erds Wit)": then it cannot go 


any further than #” since the first a copies of ¥ must. genteln, i: thus s sqation 
(6.6) contains ‘the most ‘critical window it this. is. the Cape also. . 


Finalty, suppose that (¥)* contains the most critical window. Consider the list @ 
formed by starting at the first occurrence of C[1] jn the rst. copy of #. and ending 
‘at the last occurrence of C[n] in the n + 1st copy of #.,. The: list @ must.contain 
two octurrences of C; since ¥, through ¥, contain C, and vo through Fanat contain: 


if [@] contains no occurrences of C, then.@ is a critical window. If @ is a critical 
ee then: ne. critical windew car exist: which is farger then @ since it ‘would have 
to. be .constructed out-of more than.a + 1 -copids‘of: (and =thus: would contain @. 
Thus if @ ts a critical window, it is the most critical window in (#)*. But if @ is nota’ 
critical window, then it must contain a critical window, — by the same logic this 
critical window must be the ‘most critical isin in oy. 


~~ Algorithm 6.2, LATENCY, shows how to use | Theorem 52 coupled with the algo 
rithm FLATENCY to determine the worst case labarey of. a S eanietraint with respect 
to any control structure which does not contain preemption. 
Aigorithm &.2.. ILATENCY(L, C) 
Inputs: L, control structure which does not costain nreamption. 
C, a constraint (list of task identifiers). 
Outputs: = (KC), start_index, num.tasks) 
KC), the worst case latency of C in L. 


start_index, the index in L of the ist task of the list whose weight is 
KC). 
num_tasks, the number of tasks in the list whose weight is I(C). 


1. If L is not Iterative, let (I(C), atartiindsex,:finish:index): = FLATENCYC(L, . 
C); return(i(C), start_index, finish_index - start_index + 1). 


Method: 
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2. If L is Iterative, then divide L into its iterative and norriterative (if 
any) parts: L = (¢)(¥)*. 


a. If ¥ does not contain every task in C (not necessarily in ord- 
er), return(™, -1, -1). 


b. Let K = ¢, yori where nis the number of tasks in C. Let 
(I(C), start_index, finish_index) = FLATENCY(K, C);  return(i(C), 
start_index, finish_index - start_index + 1). 


&.4: Latencies of Constraints in Preemptible Control Structures 

The next complication to be dealt with is the presence of event variables and 
multiple priority levels, implying the possibility of preemption before completion of a 
constraint, and thus additional weight for the worst case latency. In fact, at this 
point the possibility of infinite latencies arises due to lockout by higher priority 
tasks, even though the constraint may be contained in an iterative portion of the 
control structure. 

The general case of preemptible contro! structures contains many additional 
complexities, if one includes external termination of control structures, non- 
preemptible tasks, codestripping, restarting, and idle time due to stopping the flow 
of control. Thus, in keeping with the theme of building a hierarchy of algorithms 
which handle increasing complexity with each new layer, the applicability of the 
next algorithm is restricted to include all the control structures allowable as inputs 
to ILATENCY, pilus those containing <event list>’s (<event var>’s and <event cou- 


pled list>’s). Specifically there are the following restrictions: 


1. No external termination (<abort tid> or <abort cs>). 


2. No restarting of control structures (<restart cs>). 
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3. No codestripping (<codestripped cs>). 


4. No nompreemptidle tasks ikea tus durin tid> or <non 
preemptible closed cs>). 


65. No stopping of LC. The highest priority ready task must al- 
ways be initiated without delay. Thus a coe structure such 
as: . 


aaete eee (67) 
is illegal but 
~ (((A*/01)B)*/e2)C)* _ (6.8) 


Is not. Event coupled ists must contain breaks (cf. Section 


2.8.1) to enaure .that waiting for higher : priority. events In the. 
event coupled fist does not occur. 


6. Constraints must be contained wholly in a subcontro! structure, 
defined as a series of basic cs’s,. an. iterative, cs,:.or. closed cs 
fists at a single priority level. in CFG terms, a subcontro! struc- 
ture is an. acyclic. path through the control structure's CEG. which, 
contains no event arcs, back arcs or ‘breaks. This allows all pro- 
cessor time spent at any other level to be treated as an addition 
to worst case latency, and lets the details of exactly which 
tasks are contributing. to. the increase. be ignored. . Additionally, 
‘the tasks of the constraint must not be contained In more than 
one subcontra] structure... lf they are,..then the worst case:laten: 
cy in the entire contro! structure would be < the ‘minimum of the 
worst case latencies in. each. subsentral structyse. which contains 
the constraint; thus the present algorithms ‘still give an upper 
_bound. The problem here is that if tha, constraint. can:be satisfied 
by an execution which spans two or more priority levels, then the 
tasks being executed during preemption: must.be identified, and 
can no longer be lumped suether and treated as time lost to In- 
terrupts. 


7. Infinite event queues. An infinite. number (or some suitably . 
high number representing the maximum possible number of pending 
events) of occurrences of each eyent..ara remembered. This 
means that if an event happens before the previous occurrence 
has been cleared (by completion of the initiated contro! struc- 
ture), the new occurrence ‘wilt'te held ih ‘e quede and not ignored. 
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&.4.1: Definitions and General Approach 
The addition of preemption to.a control structure introduces several interesting 


timing questions. For. example: 


1. The worst case latency of a constraint as previously defined, 
i.e. the longest time that can pass without | their. baing .@.compiete, 
‘execution of each task’ tn the constraint in order. This may now 
be prolonged by /nitiation delay ag well ag. preemption dglay-_ Ini- 
tlatiorr delay is time lost’ due to the initiating event not yet neva 
Rocurred: 


2. The worst case latency of an. event, defined as the longest 
time that cah elapse between the occurrence of an event and 
the start of the subcontrol structure which it initiates. What ex- 
actly constitutes: the initiation of.a'subcontrol structare will be im- 
presentation copenden’: 

3. Related to (2), it may be desired to know the worst case exe- 
cution time of:a tist of tasks at a given priority level: this fs their 
execution time in the absence of preemption plus the most posst- 
ble time lost: to preemption. This: may ‘be moré’ usefil thar (TY ‘In ” 
cases where occurrence of an event signals the arrival of new 
data, rather then sasuming. that task lnitidtion ts ‘Ghsynchronized | 
with data arrival times. 


In all these cases it wi be. necsecary to make some assumptions which could 
lead to an upper bound which is somewhat greater that the actutl worst case (in 
addition to the uncertainty In ‘the sciinte of worst case. task, psteonton time). In 
particular, Teixeira has shown [Teixeira 78] that. the worst case ocours ‘when all 
interrupting events happen at the beginning of an interval and: continue happening 


at thelr maximum rate. It may be that the phase.re 


; 2 of. the events cou- 
pled with the execution times of their subcontrol structures le aieli that tise 
events could never all happen together; if. this, is known. in. a ‘particular case then 
its worst case may be different, and the initial phases. of the. ‘dsiante could be ad- 


justed accordingly. The algorithms do allow. specification. of event phases, as will 
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be seen. in any case the aigorithms do give an upper bound to the probiem. 

_ The worst case latency of a constraint which executes at priority 0 (the 
fowest priority) can be determined in terms of nominal’-time in the alisence of 
preemption plus time lost to interrupts; the initiation delay need.not.be considered: 
The fundamentat difference between tasks at Priority, re) and ptiorities ‘qranter than 
O ts that if the worst case latency of a constraint involves: more ‘than one execir 
tion of tasks at a priority level greater than 0, there may be delay due to ‘Initiation 


of that priority level (which must be figured according to max of the initiating 


event in the worst case) for the additional task executions. ‘The towest priority 
level is assumed to be always running or ready, —_ ‘thus as no such aay: 

In general there wil be some thought required to plapoitt the worst case for 
any time interval of interest; sonce determined,. the: aigoritha to measure such a 


time interval can be constructed using the following desk re, 


1. Determine the relative priorities of every basic cs in the 
overall control. structure, and assoqgiate with: dach. event variable 
the.subcontrol structure which It initiates (cf. Section 2.6.5). The 
priority ofa ,subcontral ao eae. leitiating event are the: 
same. It is assumed that in end rd ere known for each 


2 epee? 
“event (cf; Section’ 4.9). . 


2. Determme whether the time interval {latency or otherwise) is 
infinite. This may be done in swe steps: 


a. If the time interval is infinite In the absence of 
preemption (determined as previously shown), then it is 
mente In the Presence - Preemption. . 7 
b. Otherwise, find out whether higher priority tasks can 
sufficiently toad down the processor so that the interval 
of interest is never completed. One method for doing | 


3. If it Is not infinite, determine the interval in the absence of 
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preemption and other delays. 


4. Factor in the loss of time due to. preemption and -other. delays; 
lifting any of the restrictions given in Section 6.4 an usually be 
seen as perturbations of this factor... Si Mice Apleaceet 


5.4.2: Finding infinite tatencies” 


* es, 


The control structures represented here provide no a prior] method of guaran- 
teeing fairness. if. preemption.is present; Le.,. i ie entirety possible that in the 


worst case some tasks in the control structure may never be executed due to 


ee ue) rma es 


preemption by Higher briortty tasks. ie ea a ero 

Fortunately, It is. possible 1 to determine whether this. Is the case in advance and 
at low computational cost, and this must ‘be. done ‘before continuing with the 
analysis. 4f the latency at a given priority level ls Infinite then the iterative solu- 
tions to be “hed for solving for loss of ume ou to _preeme Uo go not converge. 
The method used te. ‘to. setermne,, a. load factor, for: or smoot) structure that 


can preempt a piven: one, and if the load is 2 1 then the given control structure’s 


tasks will never execute, 


whe 
wns 


In Sider to find the load factor due to a subcontrol structure » with initiating 


event e,, it Is necessary to partition: the:-set of events:inthte overall control struc- 


ced 


ture as follows: 


1. Egat the set of events which can always preempt ¥, but 
can never be preempted by ic ae These are the events of higher 
absolute priority than ey, as‘ found by Algorithm 2.2. a . 


2. € - This is the set of avente which cannot preempt ¢ 


win_tie’ 
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and cannot be preempted by ey but are: -chosen: over ey f ey 


and one of them are both pending at the same, time. This set is 
the: enon: of the Tonowing: sets: 


a. Events which have the same absolute priority ‘as 2 ey, 
but occur to its left in the same event coupted fist. 


b. Events which have the same absolute priority as ey: 


but occur in a different event coupled list. which.(s entire. 


ly to the left of the event coupied list containing ¥. 
c. Events which have higher ‘absolute priority then ey 
but occur:in an event coupled lst which does not contain 
ey 
3. E ose; ties This is the set of events which cannot preempt ¥ 
and cannot be preempted by ey but My! is chosen over one of 


them if both ate pending’ at'the same tiie. This set of events is. 


the union of the following sets: 


a. - Events which have the same absolute priority as ey: 
but occur to its right in the same event coer list. 


b. Events which have the same absolute priority as ey, 
but are in a different event coupled ist which is entirely 
to the right of me event coupe Kat containing 0, 


c. Events which have a lower absolute priority than Oy 


but occur in an event coupled list which does not. contain 

ae 2 
4. E never! 
e re and initiate subcontrol structures which can always be 
preempted by ey: These are the events of tower absolute priort 


ty than ey 
As an example, consider the control structure: 


(A/(e1:8/(e2:Cje3:D)\e4:E/(e6:F|e6:G)))* 
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Its preemption structure appears: in Figure 6&2, and the partitloning.of its events in 


Figure 5.3. 


re 


ee 


Fig. 6.2. Preemption structure for (5.9). 


{ @2;"08, 66 j'et 


Fig. 6.3. Partitioning the events of (6.9). 


To decide whether a task A at a given priority level ina control structure may 


hever execute, partition the events of the contro! structure relative to A as just 


described. Each event initiates a subcontro! structure (at a single priority level); 


let e, initiate subcontrol structure # r The worst case load of a given subcontrol 
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structure on the processor occurs when Its initiating event happens at Its maximum 


frequency: 


l¥, | 


Worst case load(¥ > = 
ma 


4. 


(e;) (6.10) 


The total load factor is the sum of the worst case load factor for each event which 


might participate in the biockout of ‘ this is the set E bream, ws? 
{Eaways VE Lin tie) since these are exactly those events which consistently get 


control over e a no matter how long e a may have been waiting in queue. Of course, 


if A is In the lowest priority control structure, there Is no e ‘ and the set Evin tie 


is empty; but the analysis of possible blockout due to preemption is unchanged. 


Let the events In E 


‘preempts be {e,, aes 0 ;}: then the total load ies is: 


k=j |¥, | 
Total load factor(A) = ": 
k=/ *minl®)) 


(6.11) 


if the total load factor Is > 1.0, then the task A (and any other task in the same 
basic cs as A) never gets executed; its worst case latency is infinite. All the fot- 
lowing algorithms assume that this check has been made before they are called, so 


that a finite solution is known to exist. 
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§.4.3: Delay. Due. to Preemption 
The probiem of determining the time taken up by preemption lends itsetf natur 
ally to an iterative solution. in the worst case It must be assumed that every in- 


terrupting event happens at Its maximum frequency (once every seconds). 


inin 
As the tasks Initiated by one interruption ere being executed, there may be addi 
tional event occurrences, Sausing. further delay, etc. By equation (5.11), If the 
load factor ts < 1 It is guaranteed thet at_some point the. task In question (the one 
being preempted) will execute; but it Is not clear when and for how long before it 
Is preempted again, 

The problem is then to solve for the *otal time taken to execute some set of 
tasks ¥» of total weight Wy In the presence of a set of, interrupting events 
{e;, “-*,@ yp which all happen at time zero and then again every Fmia’®? 
seconds, each initiating subcontrol structures with weights {W,, ow p> The 


att 


total time, Ty is: 


T 
k=j d 
T,"*W,+ 3 W (6.12) 
Ce ed |seatan| . 


The celling function is chosen since the -quotient 


T 
ext Oo . poe 


gives the number of occurrences for e dn: the-interval [Ty; but since alt events 
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happen at the beginning of the Interval (in the worst case) one additional oc- 


| 


but If the event occurs at the exact end of the: Mterval a this occurrence must 


=r sai 


not be counted since y wit! already be completed — thus the choice of 


[5] : | (6.15) 


A quick iterative solution to (5.12) Is had by noticing that an excelient lower bound 


is the solution to 


Ww, 
Ty zw, + "3! me wel (6.16) 
koi ®min'®x) 


a ¢ . W: i ay : 
es (6.17) 


Notice that the denominator is exactly 1 - Equation (5.11), the total load factor, 
which has already been computed. Equation 5.17 implies that running 7 with inter- 


rupts Is like running § on 4 processor whose strength has been diminished by the 
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load factor of the interrupting tasks.. 
Thus equation (6.12) is solved Iterativety by letting ae 


Ww | | | | a 
"40" agi W, (6.18) 
Rs mirl®) 
and then. solving for ‘y : i 
ae a 
Ff 
T, =W,+ ks | tees) (5.19) 
%, kot (1 Tink | * 
and “orpina wen T4, “Tb, Yo il cia tansaiy lly Increasing 
h- 


with " and this Process cones very reply » since the Initia guess Is so near 


the final abies: 

Given a computation which takes a 1 known: time-t in the absence of interruption, 
Algorithm 5.3, PTIME, commutes the bataas time taken fo do the computation in the 
presence of. interrupts, Its poe that: there is "0 > lntiation oaey involved, i.e. 
PTIME finds the worst pase interval whieh: ‘contains t ‘seconde of th » which 


preempting tasks are not executing. 


Algorithm 5.3. PTIME(t, Eo omosg) 


inputs: t,.a time which represents computation time in the ebsence of preemption. 


E preompts’ a set of events which can preempt the. computation which 
takes t seconds. 
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Output: t, , the time taken In the worst case with interriipts to perform a computa 
tion which takes t seconds without interrupts.(Le,-PTIME.assumes elt the 


events in EV cemots happen as soon as the computation starts, and con 


tinue at their maximum rate) 
Mathod: 
1. Let W, = t Let {@, 52°, 4} be the events In E veempts: Let 


{Wiicee, j2 be the weights of the subcontro! structures Initiated by 


the corresponding events. Then solve equation (6.18) far an initial vale 
of Ty; solve equation (5.19) repeatedy fer 7. using the Value of 7, 


ending when 7 =7 - Return(T 
¥n ¥n-1 +, 


5.4.4: Applications of PTHRE 
Using the. algorithm PTIME one.can determine sida rent thee properties of in 
Pernt tor Contre etipoures —— meet the restrictions of Section 6.4 ee euste 


kept in mind that there is a distinction between the folowing, pao sets of events: 


a. The set of events which can preempt a tesk after t has been 
initiated, as weil as take priority over its initiating event while it 
is pending. 

b. The set of events which get priority over an event if it is 
pending but has: not yet: beer: recognized by the processor (no | 
tasks have been initiated due to its occurrence), but cannot 
preempt any tasks In the subcontrel structure witch that event 
initiates. 


Sele ie eis 


The worst case latency of any constraint which is in the scant structure 
at priority 0 can also be directly determined. The étetinction between this peas 
tion and the one just mentioned is that the constraint need not be contained in a 
single copy of. the subcontrol structure. Since the priority 0 subcontre] structure 


hes no initiating event and hence no initiation delay, the worst case latency of a 
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constraint C can be determined in two staps: 


Algorithm 5.4. PRIOLATENCY(, c) 
Inputs: ’ a subcontro! structure which runs at i pronty 0. 
C,a constraint. : : . 


Output: 1(C), the worst case Iatency of C in a 


Method: 
1. Find (1(C), start_index, num_tasks) = IATFNCY EM, © C), the worst case la- 
tency of C In the absence of preemption 


2.. Let £ preempts ‘be the set.of at events M the entire contfol structure. 


The worst case latency of C is PTIME(I(C), E preempts ). shes 


Another application is to determine the latency of an event e;, that is, how 


agit 
w 


long Is It In the worst case between the occurrence of an event and the initiation 


of the corresponding subcontro} structure. This can be found as follows: 


Algorithm 6.5. ELATENCY(., e;) 


Inputs: «, the least amount of time that can are before a task can be con- 
sidered infitiated. Ao sg ale’ ota + a4 


. e,, the everit areres latency. le being determined. 


Output: , the longest time that can elapse after *i occurs before Its subcontrol | 
*e,’ . £ i mich d Sek bee segue . : gee . 
structure gets initiated. © 


eee 


Method: 
1. Let the set Epreampts: & CE ayeays, 4 Fwin, xe) relative to the event 
). 


2. ty = PTIME(S, Earsompts: 
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5.4.5: Adding Phase Relationships to PTIME 

For a more general formulation, it is useful to neve —— the means fas 
determining execution time in oe presence of Interruptions when the Is Interrupting 
events may have started hepbenia at any individually determined time saner than 


all starting at time zero. For this Purpose, the sense of an event is here defined as 


shoe b ey! a 


the time since Its fast occurrence. Thus ‘fore a set of events {e,. sae 1 @; } there 
may be associated a set of phases ¢ = = {6,.°° 2+,¢ be if the ‘events are. gceurring 
at thelr maximum rates, then no mora than v,,,(e,)~ ¢,; seconds can elapse before 
the next occurrence of @;- | ak = - 

In addition, there may be one or more pending sccuencs of any of the events 
on the event queue, ‘so a cet of Initély pend octirieices & = = {0,, Soon Jee 


may be determined. These two factors alter the time ‘an. to preemption equation 


(5.12) as follows: 


(6.20) 
| aC am ” I 
E k 
T (6.21) 
4 Agta : 
k=l ™min’®x) 
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The solution Is again found by solving (6.21) for the:initial: value "Wo and then 


solving (5.20) for 'y using the previous value y until they are equal. A sun 
a tog TMA i em ads 


mary Is given below as Algorithm 5.6, PHTIME. Note that if +." *min(®K) and a, 


for all k, PHTIME computes the same value as PTIME. 


Algorithm 6.6. PHTIME(t, E 


preempts’ 4, Q) 


Inputs: t, a time which represents computation time in the ‘Abesnce.of preemption. 
E reempts’ a set of events which can preempt the computation taking t 
seconds. 

4, a eaet of phases, one for each event in E 


a PRCQERpES 


&, a set of initially pending occurrences, one for-each event in E preampts’ 


Output: ton the time taken in the worst case. to perform a computation which. 


takes t seconds to perform with no interrupts. The worst case invoives 


preemption by all the events in prestipts ae ofter#-as' posslbié, subject to 


the constraints of ¢, 2, and tm in fOr, each event. 


Method: 
1. Let ha Let {e,, "4 @y } be the events in E preampts’ Let 
{W),-°- w} be the weights at’ ‘the subcontro!” structures Initiated by 
the serresonaiey events. Then solve equation (5.21) for an initial value - 
Ty! solve equation (5.20) repeatedly for ", ‘using the previous value 


of Ty: 2 , terminating when they are equal. om . Js- the velue tobe re 
n- n 
turned as ton: 
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6.4.6: Task. Execution Time-with Preeniption at PNorities > 0 
Aigorithm 5.5 gives a 1 mathod for Saterersg the pax time that can elapse 


between the occurrence of an event e, and Initiation of its” “subcontrol structure. 
This is fairly simply done since while 8; is pending the: set - of t aledts hate can 


preempt it Is static. Once its subcontro! structure has been Initiated, however, 


only events In Eaways can interrupt; however, If any of :theae events does occur, 
any event in E. iy sie Will take priority over resumption of e,’s. subcontrol struc- 


ture. 
This complicates the determination of worst case execution time (and later 
cies, as will be seen in the next sock. for a teak: subset 3 of the subcontro! 


structure, Note, however, that if the set E_ win _tie is" ‘empty (and therefore the set 


of interrupting events is static), that PHTIME can be used to get he correct result. 

in general. thaugh, the result must be found in stages, dekaralitng weit can 
be executed. The next algorithm determines the worst case time to execute a set 
of tasks 8, contained In a single subcontrol structure, given the sets of events 


Eaways and E win_tie for 8 and their initial values of. ¢ and a. It assumes that 8 


has been just initiated and then finds the time ty from. initiation tp. completion of 8, 


This is done by first finding how tong it will be before all the pending ‘interrupts, if 
any (based on ¢ and @), are processed and 8 can be resuméd:. Then the earliest 


occurrence of an event in EC ways marks the next preemption of 8. At that point 


any accumulated occurrences of events in E will cause executions of their — 


win_tie 


subcontrol structures to be completed before 8 can be resumed. This partitioning 
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of the total time taken to execute 8 is repeated until all of 8 iscompleted. Note 
that the method doss not require determination of an exact schedule for all the 
tasks In the contro! structure, although the exact ‘times when 8 will be axecuted 
are found. Algorithm: 5.7, SCSTIME (for “subeontrol structure execation time") de- 
tals the procedure. Note that -this aigotithm does not address the problem of 
determining execution time for a set of tasks Wtitch may ‘require. more. than one in- 


vocation Ot a subcontrol structure. 


Algorithm 8.7. SCSTIME(8, Eawaye! Bain _tie’. 6 » 


Inputs: 8, a sublist of the tasks In a subcontrol structure. 


Eaways relative to oy Fitting avant: 


Ewin_tie’ relative to @;- 


¢, phases for events in E aways and Ewin_tie’ af 


Q, initially pending occurrences for events in Enaye and Ewin tie: 


Output: tp the rnaeet omen time to execute 2 with phic asi 


EES LE 


é the final Ghasae-t ‘tor all the events: in .E 


win_tie’ win. tie’ 


Sin _tie’ the final ‘number of ‘Pending « occurrences foi all the events in 
- Ein_tie 


Method: 
1. Set’ anes QO, the cumulative execution time for 8. Set t, = 0. 


2. Find how long 8 can execute before it is preempted by an event from 


Eaways’ This is: 


t= MINIMUM ( min(@n? - 4%) for all ¢, © Exways (6.22) 
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Go to step (4). 


3. Find how long 8 can be executed: before an. event from E ways 
preempts it; this occurs at time: 


to = (least muttiple of # py j.(@,) >t, for alle, € Eaways). (5.23) 


fain 


4. If Sm +to-t, > I, & will complete in ‘this interval; compute ¢, =t, 
+ BI - Rint compute *win_tie | using equation (6. 25) _and substituting to 
for t 23 compute 2. using equation (6.24) and substituting io for fs 


Return (t., ). Otherwise set: Bt psf * to-t 


win_tie 


Q 


p’ 9 win. tie’ win_tie 


5. Set 2 = 1 for the event from Eatways which caused the preemption, 
Some events in Ein tie May also be pending: 


a md é 
. -|25]- [ecties] wen Fwintio sa 


6. Update phases for all events: 


ts 
9% mty- Fado ® minx? for all eo, € LE aways: VE win.tie) (6.25) 
7. Find new value of t ty the next resumption une of 8: 
t, = “ty + PHTIME(, Eaten u int tle’ + 2) (5.26) 


8. Repeat steps (3) through (7). until termination of 8 is detected in step 
(4). 
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5.4.7: Latencies for. Constraints at Priorities > 0 

The worst case latency may-be desired for a constraint which is satisfied by, 
an execution of a subcontro! structure at a priority greater than 0. If the execu 
tlon which represents the greatest fatancy invoivés two or more invocations of that 
subcontrol structure, the possibility of initiation delay must be considered as well 
as interruption delay. Each of these delays may involve a different set of preempt- 
ing events. 

There are thus several complexities to be dealt with in the general case, even 
with control structures meeting the restrictions of Section 6.4; hewever there are 
also several special cases with simpler solutions. An example ‘se: wheri’the sets 


Ewin. tle and E jose. tie are ee ig will atte shown blasted to make. use of this 


os 


simplification in a mater aector 
Recall the notation of Section 1 82, where a _subcontrot _Structure ¥ was broken : 


down Into capiierite G,, Gyr ot My, Aa) relative to a constraint C, where the 


«, *s were critical windows and the a s each contained one occurrence of c. 


PEs. 


in worst case latency of C in a control structure comaniea ¥ at a priority 


level ‘dates than zero is‘ found ‘as follows. tet ate ‘be the shianaid event for v. 


There are two candidate time hitervals which may be the worst case » latency for Cc. 


eght lggauaem 


The first, %, i Is the maximum delay between’ occurrences of ” ‘plus the daxiaua 


delay to comets bw with » preemption. The second,’ t, es he maxi me taken 


to complete @,,, the most critical window. of ¥, also with. preemption. Either one - 


may involve more than one invocation of ¢, and. henge igitiation delay: To show 
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that either % or t, could be the worst case latency for C,-consider a simple ex- 
1 m 


amipie: 


Example 5.1. ((a*/e1)B CDC) . 
where 

* max(®1) = 10 sec. 

|Al = 1 sec. 

[8] = 2 sec. 

jC} = 1 sec. 


jo} = 3 sec.. 


The most critical ‘windows for the constraint (C) Is ‘ D c), with a weight of 5 

seconds. However, the longest time that elapses without an occurrence of C is 13 

seconds, which Is ty. , or * max(@1) + 18] + {ch it Pl were changed to be 16 
1 

seconds, though, (C D C) would es be the most critical window tor (C), but now 


t is 17 seconds, which is arduter than * 
m 


_ Thus the two candidate times must be computed and their maximum returned 
as KO). Note that since the enue control enucure is repeated, the, task list 


atereny: at B, and wrapping around baie Lee is a critical window, call it tay and. 
must have weight greater than Pai therefore 2 cannot take moe than It to exe- 


cute, and need not be considéred as a candidate for "C). Furthermore, it might be 


thought that the weight of «, plus the delay due to Initlation of its second part, B., 


may in total be greater than the weight of an otherwise most critical window which 
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Is contained In ¥ and hence has no Initiation delay associated: with it. To show: this 


is untrue, It Is only necessary to show that the weight of a, with Initjation delay 


must be less thant, and t, , since the addition of delays due to interruptions Is 
A : m : 1 z * Snes ae e meg : 


a monotonically increasing function of the time. taken without. interruptions. 
Thus assume that a “o is not the most critical window of ¥ for c Cif it Is, it will 
be considered by the ergorttnns and thus there - no need to justify Its exclusion). 


But if this is the case, then there Is a critical window" «. in ¥ with greater welght 


than «9; thus the time to execute aig is jess than or equal to 
legl + (max(@y)- el) hee). 


in the absence of interruptions. But since legl Is s « Hemb equation cS 22) Is < 


ge! 


max'®y): This in turn is less than ty which tichides ° ax(®y) | as one oF Its sum 


mands. Thus it Is sufficient to find the maximum of t, and t. 
1 m 


Consider the computation of t. . First the most criticel window must be found © 
m ‘ 5 2 


for C in # using the algorithm for iterative control structures, ILATENCY.. ‘Note that 


In this case since the entire subcontrol structure gets repeated, the head (8,) of 


(¥)* containing C cannot hep Sent eae worst latency for ¢ oy Heer (without initia- 


tion delay); there ‘must be a critical sai of greater weight which includes ee 


as its cesta occurrence of C. 


Therefore [LATENCY will return I(C), the weight of the most critical window an 
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in (§)*. LATENCY also returns startindex, the index In 9 ‘of the first task of «_, 
and num_tasks, the number of tasks in«,,. Knowing this, it can be determined how 
many times e,, the initiating event for $, must occur during «p's execution (i.e., by 
knowing how many copies of ¥ are included in =, 2y, Partition «,, vate ie subbate 
{¢m "ma: * + 4m} where each “m, is a portion of «which is contained in (a 
single copy of) ¥. Since t, Is the longest possible time to execute « , t must 
be assumed that all the interrupts happen immediately after. initiation of «,, and 
continue at thelr maximum rates, while the initiating event e, happens at its 


slowest rate. 
Figure 5.4 shows the time line for part of a sample execution of a critical wir - 


dow «,, which is not contained by a single copy of #. 


ee a eae aaa at alc ce te fae acl ala | 
e ¥ « « @ « 
¥ starts m m ¥ m 
occurs 1 1 occurs 2 
starts ends. second starts 
time 


Fig. 5.4. Partial execution of a critical window om" 


In the worst case, the Initiation delay of interval (4) is be the maximum possi 
bie, with the constraint that Interval (3) must be at its maximum too Greatest 


amount of time lost to Interrupts}. Therefore the iterate (1) and (2) must be 
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computed: at their minimum, i.e.: no preemption: Thus intervat (1) is assumed to be 


zero, and interval (2) is fy] - mn 5 |. “This may Givé“an lated upper bound by 


aoeenns interval (4); if it is Known in a particular case that preemption must 


Buea Peay 


occur during intervals qa) and (2), « an adjustment can be 0 made | in the a of the 
interrupting events at the beginning of interval (3). nee 
- AS was previdusty stated, Tt 18 assumed that the worst case is when all events 


occur right after « - 


m, starts, ‘so the length ‘o f “interval &, tay is found ‘trom 


2 Piakese re 
a3 Tewari. ns 4% gee Bes 


,E 


SCSTIME(¢m » Exways’ Ewintie’ * 


2) where and E are deter:. 


ine win_tie 


mined. relative to ey, = (0, .., 0) and @ = (1, . 2, “FY for att the events.” 


Once the interval times ‘oy ‘ey * ‘and’ ‘oo are s dctermiod: ti. ‘) ‘s fourid ye 


“4 inl ietas gs syitey th > rere 29) Can 


“teas nn, salts: Ngan Hay thay] - ares 


If a) > O, there Is an:initiation delay which must be factored into the solution. 

“At this ‘point’ andttier d&cision must be made which affects the tightness of ‘the 
upper bound determined by the ‘algorithm: *‘Buring interval (4), any of the events in 
the control:.structure other, than e,,.may ‘get ‘cértrol, ‘and tfiere may be arbitrarily 
complex blocking out among the different sats of eventadye:to the exact order of © 


eccurrences; l.e., to get the true picture, ia Raastre raways’ Ewintie. and a 


get Repth? 


Eose_ tle relative to every event must be spe ta since the reference oon 


provided by knowledge that a was * pending f has been lost. “This makes 5 nding an 


civaiytic solution fie the values of ¢ and 9 at the end of interval (4) quite compi+ 
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cated, and two alternatives. are provided here instead. Note that the relative im 
portance of this is dependent on the, relative size of triterval. (4); in the extreme 
case, if it is zero, then there is no probiem at all. 

The simpler method (and the one used here) is to assume that all events in 


and E 


win.tie get blocked out during interval (4), and thus their ¢'s and as 


Eaways 
get updated accordingly. This will provide an upper bound which is high by the 
amount ‘sf execution of preempting tasks which could have taken place during inter- 
val (4) and will now instead be added to the preemption delays of the next inter- 
sae wy eh od. : ph 

Unfortunately, this is not the only complication. In, the worst case, en event: 


from E;o60 tie might get control just beter pie me a Interval (4), and Initlate a 
subcontrol structure which could not be preempted by ey: The event e, in 
Ese tie Which Initiates a subcontro! streoture ‘that runs for the longest time 


without being preempted by an event In E 


‘always. EVin.tie (aiven thelr ¢@’s and 


&s at the end of Interval (4)) is chosen, since once it gets preempted it has less 


priority than ey by definition. Let the length of this time be t,,.and then the time 

until “mo starts is given by PHT IME(t LE anveys WE intieh @,.2).. The ¢’s and 

Q’s are updated and the process is repeated as from the start of, _, terminating 
1 


when the end of an ‘is reached. 
n 


The alternative method is to determine an exact schedule for interval (4). 


Then It will be known whether or not an event from eat tle can get control and 
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keep it past the end of interval (4), and the exact ¢’s -and 0’s for all the events 
can be determined. This Is the method of choice if the initiation delay Is known to 
be significant. 


The interval *s, Is measured on a slightly different time line: 


paren Oren goed aee |Srecgiers [eect etsy | Resa tore Bie 
e 8 a e B 
¥ 1 1 a 1 
occurs 1 <> Al occurs 2 
starts ends . second starts 
_ time 


Fig. 6.5. Partial execution of B,- 


To find ‘s,’ the execution of B, is broken down into parts which are contained in a 


single copy of ¥, just as was done for a: Here the worst case Is when all inter- 


rupts happen at the beginning of interval (1) and continue at their maximum rate, 


since the length of interval (0) Is fixed at ¥max’* yi this gives the greatest delay 


during Interval (1). Interval (1) is thus the maximum initletion delay for # with 


preemption, including the possibility of an avent from E ose tie getting control just 
before ey happens and causing further delay as previously discussed. The times 


of the remaining intervals are found as was done for. the fn *s, computing the initial 
i 


@’s and .&s appropriately. 
This procedure is detalled In Algorithm 5.8, LATENCY. 
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Algorithm 5.8: LATENCY(C, $) 
inputs: C, a constraint 


¥, @ subcontrol structure containing all the tasks in C, in a control struc- 
ture meeting the restrictions of Section 5.4, and where the worst case la- 
tency of C is knowm not te be inflaite by equation (6.11), 


Output: i{C), the worst case latency of C in the control structure containing ¥. 


Method: 
1. Find KC), start_index, and num_tasks by executing !LATENCY((#)*, C). 
tet «,, ENG oe rer ere ee een ee are 


bane teak: 

2. Find the sublists of a): fm my ”, 
the completely contained in a single copy of-¥. if the number of tasks in 
¥ is k, er ta W{[start_index} through ¥[k], «,, gE <n =, 


My-4 
and “m, = ¥[1]} through ¥[num_tasks - A(n : 2)-&k- erarcinnes + 1)} 


) where each “m, Is 


3. Since the worst case involves maximum initiation delay for $, assume 
intervats (+) and (2) (see Figure 5.4) ejapge without preemption. Thus: 
(4) = O and t(5) = WI- ke jb and yt) * troy at the start of interval 


(3). 


4. Find the sets Eways’ and Ewin tie reais to'8 5: Set ¢ = 0 and & = 
“+ for all events in these sets. Find the set E/00, tq relative to ey. Set 


t,. = 0. Initialize the counter / = 0. Repeat steps (5): through (7) until 
a Coat 
the end of «,, is reached in step (5). 
a if 
6 Seti = j + 1. Find %,) = t which Is returned by 


Pp’ 
SCSTIME(a,, + 2). Set t, he + Kar | Set ¢ and. 2 


7” Falways’ © win tie” By 


returned 
by SCSTIME. It f= m go to step (6) where ty ‘te éowputed. 


6. At the end of t/5), since «,, was in control, none of the events in 
é 


E ways was pending. Thua set 2 = 6 and: 
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, 


m ; 
+," te. - |e emilee each sha e, € {Eaways} (5.28) 


and the following must be done: 


a. Update ¢ and @ for each event e, in {Eajways VE Lintied 
+¢, | | 
$= 4) OK SK min? {8/30) 


© Enso tie Which initiates a subcontrol 
structure that can run the longest before (or without) being 
preempted by an event in {Eaways UE intiedi this can be done 


by considering each event In E,., gj, in. turn. Let. te, be the 


b. Find the event @, 


time which elapses past the end of interval (4) due to e,. 


c. Find the initiation delay of «,, —: 


i+1 


> {ea ways (6.31) 


tuelay © PHTIME(t, VEVintied * 9) 


d. Set t =t + +t ; 
mn  “m a) delay 


e. Set a, =O, and: - 


. 


= - —__m__ Z : 4 
tte = _ ®min(®k) (6:32) 


for all events @, in {Eaways U EWwin_tie) 


If ta) is zero, set +, ™ % + 3) - ® max'*y)- 
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‘8. Find s,3 find 8, of (¥)* by scanning until the first occurrence of C 


enn enee Divide p, Into aubligts! as was ‘done for «), ih step (2), 
getting as a result @, 11g yore “By ), where this n may be different 


trom the n obtained for «,, 


9. Refer to Figure 6.5. The time of interval 9), Yoy 's * max‘®y)- As- 


sume all events in {eways VEvin tie? occur at the end of this interval, 


and continue at their maximum respective rates. Thus set 2 = 1 and ¢ = 0 
for afl these events. Let %, =to)! let./ = 0. Starting at step (7b), ex- 


ecute just as for «,, cubottuting ty for . and ay, for “m, 


10. Return seca Fr t, ) 
/ m 


&.6: Special Cases and Extensions — 

There are many special cases which result in much simpler algorithms. Each at 
gorithm presented in the previous. section la: directed’ towards a subset of control 
structure types which contains the previous subsat and some additional control 
structure types; it is seen . that in general, as the number of ancrant types in the 
subset Increases, so does the complexity of the resulting algorithms. 

As an example of another important special casa, conaider finding any of the 


reattime properties for a subcontrol structure whose sets E,,., 4. and EL, sie 


are empty, e.g., as would be the mane @ controt-strudture containing no event 
coupied lists. Now all of the complications sue. sad having | ae ast of preempting 
event variables change dynamically drop ‘out - “the statically determined set 


Eaways is the only set that may preempt, and by definitin it can always preempt. 
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The simpiifications this Introduces are substantial; take the most complex of the 
algorithms of the previeus section, Algorithm 6.8, LATENCY, for exampie. In step 
(65), SCSTIME can be replaced by the simpter-PHTIME. There may still be an initia- 


tion delay tg), but there Is no tonger the possibifity of an event from E),., sie 


getting control arid prolonging the initiation time. 

As far as extensions to the algorithms go, there are two principal areas to con 
sider: one is the determination of algorithms for real-time properties not discussed 
here and which are germane to a specific application, aha the other is the lifting of 
the restrictions of Séction 5.4 to allow any representable control structure to be 
analyzed. Since the first area requires an application relative to which suitable al 
gorithms can be developed, only the second area will be covered here. 

The difficulty involved In lifting the restrictions of Section 6.4 varies consider- 
ably from one restriction to the next, ‘and hence’ they are ‘disctissed here one at 
time. The following discussions are not Intended’to be the final word on the topic, 
nor are all the details suppiled for a ‘perticular method of itfting each restriction. 
Instead, the intention is to point out the difficulties invélved: in’ each case and to 


make suggestions as to how they might be overcome. 


5.6.1: External Termination 

Recall that there are two types of: iteration, in effect, that can be applied to a 
subcontrol structure; local. and global. if a subcorntrof structure is locally cyclic, it 
means thet that particular subcontro! structure executes indefinitely, without requir- 


Ing reinitiation by Its Initiating event. This le equivalent, then, to having an event 
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which initiates a subcontrol structure with Infinite weight. If, instead, It is part of a 
globally cyclic. control structure, then it too will. be repeated indefinitely, but only 
one time per. initiating event occurrence. Both of these types are allowed under 
the restrictions of Section 5.4, because the weights of the Initiated subcontrol 
structures are fixed, even though they may be infinite in the locally cyclic case. 
However, there Is the potential for a subcontrol structure which haa infinite (and 
thus fixed) weight with no external termination to have varying weight in the pres- 
ence of external termination. Thus the delays encountered In the. execution of 
lower priority control structures due to interrupts, which. Initiated <abort cs>’s 
(those which may be externally terminated) will vary according to how long the 
<abort cs> executes before /t gets preempted. An upper bound on this time can 


be found if a good value Is known for #, 


of the terminating event; if there is 

more than one such event, the. minimum of their maximum periods may be used. 
Note that this also complicates. the determination of joad factor (equation 

(&.11)), since that depends as well.on heving. a known upper bound for the weight 


of each subcontrol structure. 


6.5.2: Restart Control Structures 

This is another case which may lead to variable subcontrol structure execution 
times. Every time a <restart ca> gets preempted, the time of:its currant execution 
Is extended by its nominal weight in the absence of preemption; Ris essentially 
the opposite of external termination. Thus a. <restert ca> needs a@ horpreempted 


Interval equal to its nominal weight In which to execute.. To. find. wirether such an 
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interval exists, one must see whether the phases of all the events in the sets 


and E relative to the <restart cs> can be adjusted so that it gets 


E ways win_tle 
preempted at least once every |<restart cs>] - « seconds. This can be either very 
simple, as in the case where there {is only one event that can preempt the <restart 


cs>, or very complex, if there are many events and their interrelationships must be 


considered. 


5.6.3: Codestripping 

This Is somewhat simpler to handle. If one of the interrupting events initiates 
a <codestripped cs>, then the delay it causes Is simply Its nominal weight divided 
by the number of codestrips, e.g. the weight ef (A/6) Is Just JA]/5. If the tasks. 
whose execution time is being measured are codestripped, though, it is as if they 


were preempted by an event with variable * mi 


ee to get this effect, a dummy 
event can be substituted for the integer which tells how many codestrips there 
are, and its phase can be adjusted every time the <codestripped cs> Is resumed 
so that it will cause preemption at the time when a single codestrip would have 


finished. 


6.5.4: Non-Preemptible Tasks 


Let Vranas be a subcontro! structure whose reattime properties are being 
measured. Then If a subcontrol structure of higher priority than # includes 


non-preemptible tasks, the effect on ¥ Is unnoticeable - these tasks would 


meas 
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have been executed to completion anyway before Len was resumed. if all of 


¥ meas 1% NoMpreemptible, then its computation time need not include the effects of 


those interrupts which cannot preempt it, and the sets E, ways and EWintle can 


be adjusted accordingly. !f only a part of ¥moas is non-preemptible, then the ¢'s 
and 2s of interrupting events must be updated when the non-preemptible part has 


been executed. If a subcontro) structure of lower priority than V meas is non- 
preemptible, then if the Interval Vines includes an initiation delay, it must be in- 
creased by the maximum amount possible due to execution of tasks which ey can- 


not preempt. This can be handied similarly to the case where an event from 


lose_tie 9ets Control just before e, occurs. 


5.5.5: Stopping the Flow of Control 

This is another case which may result in effectively varying the weights of 
subcontro!l structures and hence the deiay due to preemptions which include their 
execution. It has some similarities to external termination; consider the example 


given in equation (5.7), repeated here: 
((((A*/e@1)B)/e2)C)* 


The problem is that the effect of the delay In executing A due to e1’s occurrence 
ts dependent on the perlod of e2 - hence the similarity to external termination. 
The difference is that the minimum effective weight of B is still |B], since an oc- 


currence of e2 before the end of B preempts 8, but leaves the remainder of B to 


-100- 


Stopping the Flow of Control Section 5.5.5 


be resumed once C is done. 
Thus the techniques for externaltermination canbe applied ‘here, with the con- 


straint that the minimum weight of:a subcontro! structure Is stiff Its nominal weight. 


5.6.6: Constraints at More than One Priority Level 

To be able to consider the worst case latencies of constraints whose member 
tasks are found at different priority levels and thus in different subcontro! struc- 
tures is a difficult Srobleni: To determine this, the executions of tasks at lower and 
higher priority levels can no longer be lumped together and treated as a delay, 
since at the very least it must be known ihe every task which occurs in the con- 
straint Is executed, regardiess of what its priority may be. Thus algorithms of a 
very different sort from those in the dielous sections are probably required, and 
the possibility of simulation to detaraiie ee . exact schedule may provide a starting 


point. 


6.5.7: Finite Event Queues 
if only a finite number of event occurrences can be remembered, and this 
number is small enough so that some event occurrences are ignored, then from 


¥ meas’ s point of view, the delays due to preemption beuaicite previously may be 


too high but cannot be too low. The equations which determine the time lost to 
preemption must be adjusted to Include a maximum value of a. 

When sauting initiation delay, it duze now be ‘seen whether, in the worst 
case, the initiation delay may be prolonged due the initiating event's occurrence 


being ignored. 
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6: Conclusions and Directions for Future Research. 

A new notation has been given which represents realtime control structures ‘at 
a high (task and event) and impiementatiorfree level, Including sequencing, Itera- 
tion and preemption as primary constructs. The notation can represent conventior- 
al single and multiple level Interrupt structures ax well as one tea detiodal Bree 
where branching of ne preemption structure is sores’ A total priority order- 
ing may be described, or arbitrarily many events and subcontrol structures may re- 
side at the same priority level. An aigorins Is oiven for determining the preemption 
relationship for any <event, task> couple in the control structure, as } well as a conr 
pletely deterministic method of selecting a task tor service if several events with 
arbitrary priorities are pending (possibly equal). it may be Interesting to consider 
the modifications necessary to the algorithms if it is assumed that the processor 
chooses at random from among all the pending events of the highest priority. 

Additionally, notation is given for representing task termination by external 
event occurrences (as opposed to temporary Preemption), describing _whether a 
control structure should be restarted from its ‘fest task or resumed from the. point 
of preemption, codestripping, and masking of a bias of interrupts while any given 
task Is executing. tt is shown that due aa ne eesumed: _transitivity of the. 
“preempts" relation, the sets of events chosen for these rece cases might 
necessarily Include other events not explicitly mentioned. 

The notation Is compact, and provides a convenient format for conveying a lot 
of Information about the control flow relationships among the members ot a set of 


tasks. A complete BNF specification is provided, and a “parser can +s (and has 
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been) constructed using any of a number of extant compiter-compilers which accept 
BNF specifications. 

Classes of represéntable contro! structures are given, typed by the topology 
of their control flow graphs. “It Is shown’ that partial as welf as total orderings of 
tasks and events can be achieved through the use of the event coupled list, which 
introduces forks into the control flow graph. A method for recursively constructing 
@ muitipte priority levet contro! structure of the traditiofial type Is given. The dis- 
tinction is made between: 4 contro! structure which supports 4 processor priority 
and one which actually has‘bniy a’strigié tevel of Interrupts; even though there may 
be a set of severat interruptitig events which are ordered among themselves. It is 
shown that while in generat the need for this ‘type of contro! structure Is perceived 
to be strongest ‘In situations where representation of periodic events and task exe- 
cutions prevalis, aperiodié contro! structures aré’ represéitiible. However, a true 
tree-shaped interrupt ‘structure cannot be acttevéd ‘due to the transitivity of the 
“preempts* relation. in addition, while Heration can be ‘applied to any closed or 
basic. control structure, a back arc cannot origiiate ‘from the middie of one event 
coupled liet-and terminate inthe infddie ‘of aiéther:” This is not felt to be a serious 
restriction, however, sined it ls Ikély that grédps of tieks In a siibcontro! structure 
are related and expected to be executed as ‘a block. * i il 

The: second half of the thesis concentrates on describing the sorts of reat-time 
properties which may be of Interest to a user of any réaFtime system, and demon- 
strating how they can be measured for control ‘structures representable using the 
notation presented-here. The worst case faténcy of a tofistraint Is found to be a 


property whose determination involves computation of ‘several other properties as 


-103- 


Conclusions and Directions for Future Research i. Section 6 


Subroutines. The difficulty. of finding an. upper. bound on task. execution time ts dis 
cussed, although without this knowledge it Is doubtful that much further.analyais of 
value could be performed. Additionally, bounds. on. the maximum. and minimum: period 
for each event are needed. The algorithms, refiact reality, ia that If fhese periods 
are not known, it will be difficult to forecast reattime: performance for the control 
structure. a). Ee 

Next several algorithms for measuring latencies are developed, each handling a 
larger set of contro! structure types, up to a. level. which .jncludes the entire basic 
framework of sequencing, iteration and preemption. Along the way, it ig shown how 
to determine if a response time might be: infinite, and.it ls. asgumed that this Is done 
before attempting to use any of the algorithms: for meesuring. the variaus time inter- 
vais. An algorithm is given which determines the loss of time due. to preemption if 
the set of preempting events. is static, and hy using it it is:-shown:how.to determine 
the latency of a constraint contained in a prigrity. 0.subcontrol. structure, and the 
worst case Initiation delay for an event at a given. pricrity level. The worst case 
assumed here Is the occurrence at the beginning of an interval..of all interrupts, 
and their reoccurrence at their individual maxiqua rates,, However, an.aligorithm is. 
also given which determines preemption time: if. the phase_of each event is known 
at the beginning of the interval being measured.. 

The effects on these algorithms of adding control structures: containing each of 
the restricted items of Section 6.4 Is considered; . further investigation is needed: 
here to uncover the details of the problems which. are-peinted out. Another useful . 
thing would be to develop analyses based on a probabilistic model. rather than on 


the worst case; e.g., what is the probability that a given constraint will have a la- 
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tency of no more than n seconds? Finally, an important result would be the 
development of a general algorithm which could determine the latency for any of 
the representable control structures,. The difficulty of such a-taak should not be 


underestimated; indeed, In the words of Niklaus Wirth: 


It does not appear feasibie at this time to postulate any generally 
valid and at the same time practically useful rules for the determi- 
nation of execution time bounds for systems using processor shar- 
Ing. [Wirth 77b] 
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Appendix A: Summary of BNF for Reaktime Control Structures 


Sent structure> ::= <basic cs> | <closed cs> | <iterative cs> 

<task id> ::= <letter> | <task id> <alphanumeric> 

<letter> := A] BI] C]...4Z 

<alphanumeric> ::= <letter> | <digit> 

<digitD := Of 142] ...] 9 

<basic cs> ::= <task> | <basic cs> § <task> | <basic cs> T 

<task> ::= <task id> | <non-preemptible tid> | <abort tid> 

<closed cs> ::= ( <basic cs> ) | ( <preemptidle cs> ) | ( <closed cs list> ) | 
( <closed cs> <preemptibie cs> ) | { <closed cs> <basic cs> ) | 
( <restart cs> ) | <non-preemptibie closed cs> |] <abort cs> 

<closed cs fist> ::= <closed cs> | <closed cs list) <closed cs> 

<iterative cs> ::= <basic cs>* | <closed cs>* ] <basic cs> <iterative cs> 

<preemptible cs> ::= <control structure> / <event list) | <codestripped cs> 

<event var> ::= e<integer> 


<integer> ::= <digit> | <integer> <digit> 
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<event list> ::= <event var> | (“event coupled Ast>) | 

(<event coupled list>)* 
<event coupled list> ::= <event var>: <control structure> | 

<event aes oe - <event var>: eeobsed enacts 
<nompreenmptible bad i “Ctask> | ‘(Kev Het>)<task> 
<non-preamptible closed os> ::= ‘<closed’es> | ‘(<ev list>)<closed cs? 
<ev list> ::= <event var> | <ev lst>,<event var> 
<abort tid> ::= @<task> | e(<ev list>)<task>- 
<abort ca> ::= @<etosed ca> | @(<ev list>)<closed ca> 
<restart cs> cal > <basic cs> | > (<ev fist>) <basic cs> 


<codestripped cs> ::= <basic cs> / <integer> 
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